Re: how to interpret info from gdb core (233 Views)
Reply
Frequent Advisor
Reggie Chang
Posts: 68
Registered: ‎01-30-2002
Message 1 of 6 (233 Views)

how to interpret info from gdb core

Hi there,

I got a Fortran code and unfortunately got
core dumped during execution. I ran
"gdb executable core" and got some display.
(see bottom for the partial clip) It seems
the folw of execution with subroutine names
is displayed and indicates subroutine utzerd
is where the problem occurred. What is the
meaning of +0x1c0 appearing with utzerd_?

Thanks.


Reggie

..(no debugging symbols found)...
Core was generated by `zz.bin'.
Program terminated with signal 10, Bus error.
(no debugging symbols found)...
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...#0 0x40000000001e50a0:0 in utzerd_+0x1c0 ()
(gdb) where
#0 0x40000000001e50a0:0 in utzerd_+0x1c0 ()
#1 0x4000000000b44db0:0 in asefrq_+0x4120 ()
#2 0x4000000000a87690:0 in asegst_+0x8900 ()
#3 0x4000000000165790:0 in _start+0x21f0 ()
(gdb)

Acclaimed Contributor
A. Clay Stephenson
Posts: 17,825
Registered: ‎07-16-1998
Message 2 of 6 (233 Views)

Re: how to interpret info from gdb core

A stack trace is only marginally useful unless the code was compiled with debugger info on (typically -g). All you know at this point is the function/subroutine where the failure occurred and the chain of functions/subroutines that called them. If you have the source code, compile with -g and no optimization. Run the executable and now the debugger can give you more meaningful data -- the actual source file and line of code -- unless the error occurs in a library for which you don't have the source. Even if you don't hasve the library source, the stack trace can show you the function arguments.
If it ain't broke, I can fix that.
Frequent Advisor
Reggie Chang
Posts: 68
Registered: ‎01-30-2002
Message 3 of 6 (233 Views)

Re: how to interpret info from gdb core

Clay,

Thank you very much for the message.

After I used -g and removed -O2 in compiling
command, I did not have any error message! Do
you think the compiler might be an issue? Our
version is F90 v2.7.1.

Another possibility could be about memory allocation (clue of Bus Error). However, it
is funny w/ -g and w/o -O2 will make such a
difference.

Best regards,

Reggie
Acclaimed Contributor
A. Clay Stephenson
Posts: 17,825
Registered: ‎07-16-1998
Message 4 of 6 (233 Views)

Re: how to interpret info from gdb core

You could have simply moved the bug around so that no segmentation violation occurred. The hardware can only detect such trespasses when a page (4k usually) boundary is crossed; however, what you are seeing is not all that uncommon and it generally is caused by a bug in the optimizer. I would next try w/o -g but also w/o the optimization on. I would, of course, look for compiler/linker patches and install them.
If it ain't broke, I can fix that.
Frequent Advisor
Reggie Chang
Posts: 68
Registered: ‎01-30-2002
Message 5 of 6 (233 Views)

Re: how to interpret info from gdb core

Clay,

Thank you very much for the help.

Reggie
Frequent Advisor
Reggie Chang
Posts: 68
Registered: ‎01-30-2002
Message 6 of 6 (233 Views)

Re: how to interpret info from gdb core

patch might be the solution since the problem
went away without -O2 flag.

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.