[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