internal-error: insert_step_resume_breakpoint_at_sal

Nick Roberts nickrob@snap.net.nz
Wed Jan 26 20:48:00 GMT 2005


 > > However, I don't know how to get a backtrace as sending SIGINT (actually
 > > SIGSTOP with Emacs) interrupts the bottom level process (Emacs in this
 > > case). I can then interrupt the GDB being debugged, but presumably by then
 > > things have changed.
 > 
 > You can attach to gdb - $ gdb gdb <pid> - and then get a backtrace that way.

Ah, yes! It just tells me GDB is waiting. Perhaps that was obvious but I had
hoped it would be looping as that would have been a problem that I could have
debugged.

#0  0x4012e7e9 in wait4 () from /lib/libc.so.6
#1  0x4012e787 in waitpid () from /lib/libc.so.6
#2  0x0809b2e2 in child_wait (ptid={pid = -1, lwp = 0, tid = 0}, 
    ourstatus=0xbffff1d0) at linux-nat.c:1689
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x809b2fd.
#3  0x080f98ea in wait_for_inferior () at infrun.c:973


 > Anyway, same as before, lets look at a transcript (see the script 
 > command) with "set debug infrun 1" (and perhaphs also "set debug target 
 > 1" - that one is really verbose).

Its attached below. GDB isn't hanging as it spews out more output from infrun
if I move the mouse around in Emacs. Its just not letting Emacs reach the next
statement.


Nick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.txt.bz2
Type: application/octet-stream
Size: 881 bytes
Desc: gdb infrun log
URL: <http://sourceware.org/pipermail/gdb/attachments/20050126/66d91b85/attachment.obj>


More information about the Gdb mailing list