[patch/rfc] Add a sentinel frame
Michal Ludvig
mludvig@suse.cz
Tue Feb 25 16:24:00 GMT 2003
Andrew Cagney wrote:
>> Then run mainline GDB on x86-64:
>> (gdb) break main
>> (gdb) run
>> (gdb) print func(1)
>> ../../gdb-head/gdb/sentinel-frame.c:102: internal-error: Function
>> sentinal_frame_pop called
>> A problem internal to GDB has been detected. Further
>> debugging may prove unreliable.
>> Quit this debugging session? (y or n)
>>
>> Attached is a backtrace of this failing GDB.
>> Any ideas?
>
> Yes!
>
>> #6 0x00000000005446d1 in sentinel_frame_pop (frame=0x82c100,
>> cache=0x82c130, regcache=0x850610) at
>> ../../gdb-head/gdb/sentinel-frame.c:102
>
>
> At this point GDB is hosed.
>
> As I mentioned before, popping the sentinal frame is meaningless so the
> question is, where did that frame come from.
>
> A wild guess is that it is trying to pop the dummy frame having finished
> the inferior function call. A confirmation is:
>
> (gdb) break func
> (gdb) print func(1)
>
> It should manage to stop in func, the stack being something like
> (assuming bt doesn't also internal error :-):
>
> (gdb) bt
> .... func ...
> .... <dummy-frame> ...
> .... main ...
Hmm...
(gdb) b func
Breakpoint 1 at 0x4000040f: file prog.c, line 1.
(gdb) bt
#0 func (arg=1) at prog.c:1
#1 <function called from gdb>
#2 func (arg=1) at prog.c:1
Cannot access memory at address 0x3320303236383ae0
Ad #2 - I was in main before 'print func(1)', not in func()...
> Returning from func(), causing the dummy-frame to be discarded should
> then trigger things:
>
> (gdb) finish
> ... barf ...
(gdb) fin
Run till exit from #0 func (arg=1) at prog.c:1
/ttt/64/src/gdb/sentinel-frame.c:102: internal-error: Function
sentinal_frame_pop called
[...]
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
More information about the Gdb-patches
mailing list