Re: Does print statement will effect the behavior of program?

On 10 25 , 12 26 , dpb <n...@xxxxxxx> wrote:
Fortran Learner wrote:

...



The problem is, when I try to run that old program, if the lines
start with * are commented, the program will stopped with the
information "forrtl: severe (174): SIGSEGV, segmentation fault
occurred".

But If I drop the * (uncomment the related lines), it will worked. I
am wondering what happened here. And I also found that the program
will stop unless print all the realted varibables.

Here is the related code.

DO 14 I = NCORE+1,NORB
* print *, I, NREF
* print *, IOPTR(I)
* print *, JWLIST(I,IOPTR(I))
IOREF(I,NREF) = JWLIST(I,IOPTR(I))
* print *, "Here no problem"
14 CONTINUE

Some related variables are defined and initialized like this, also the
preset value in the iteration:

NCORE : undefined, but initiaized : NCORE = 0, Present value is:
9
NORB: : undefined, but initiaized : NORB = 0. Present value is:
12
IOPTR(I) : defined in a common block, but NEVER used before the
ieration. ...

This has all the characteristics of out of bounds array access combined
with the possibility of uninitialized variables in either the loop
indices or arrays.

Changing symptoms with the inclusion/exclusion of print statements (or
any other executable code for that matter, it's just so commonly seen w/
i/o owing to the tendency to add debugging statements) is probably one
of the most faq's ever.

I'd suggest compiling with all possible debugging options on,
particularly array bounds checking.

Also, if the code doesn't use implicit none that would be a good start
as well to eliminate all compilation errors arising from its inclusion.

Many codes relied on the nonstandard behavior of some compilers to
initialize variables to zero -- this may also be a case here. While not
a recommendation as to a solution (all variables should definitely be
initialized explicitly), for debugging you might try whatever is the
option for that with the particular compiler you're using.

--

Thank you very much Mr. dpb. Last time I found a problem in another
program is just the case you mentioned here.
I will try to check it according to your advice. If I got some
progress, I will up-date this post immediately.
Thank you again.

.

Relevant Pages

  • Re: Does print statement will effect the behavior of program?
    ... This has all the characteristics of out of bounds array access combined ... I'd suggest compiling with all possible debugging options on, ... initialize variables to zero -- this may also be a case here. ...
    (comp.lang.fortran)
  • FreeBSD 4.8, ASR2120, SMP, degraded RAID1/mirror => storage failure
    ... upon a RAID array degradation event (a disk is ... The same happens upon boot with a rebuilding/degraded array ... Attached is a tarball with debugging logs. ...
    (freebsd-questions)
  • Re: java deferred GUI painting considered harmful to sanity
    ... There is an array, it just doesn't have any elements. ... pounded with error messages modelling this metaphore, some asynchronous painting update fails mysteriously, and the result has always been a next-to-impossible debugging chore. ... It should be possible to _force_ painting updates to be synchronous with the changes that cause them, even if just for purposes of debugging muck like the above, later to set the painting updates free to be asynchronous again in the delivered code. ...
    (comp.lang.java.advocacy)
  • Re: gdb stepping into boring stuff
    ... The "step" command doesn't step into functions that have no debugging ... hash table within the gdb convenience variables (which I think is ... with the $known_uninteresting_pc being kept as an array local to the ...
    (comp.os.linux.development.apps)
  • Re: CASE...OF
    ... an associated array of xt values for the words that handle each case. ... rather than just comparing the values sequentially. ... compiling a CASE statement using IF and ... but I have a word called SpecialCases that checks the XT (CFA in my ...
    (comp.lang.forth)