Re: gdb + sigtraps

[christos%astron.com@localhost (Christos Zoulas)]

In article <jmfpd0$r7g$1%dough.gmane.org@localhost>,
Christos Zoulas <christos%astron.com@localhost> wrote:
>In article <20120415135229.GA12625%quartz.inf.phy.cam.ac.uk@localhost>,
>Patrick Welche  <prlw1%cam.ac.uk@localhost> wrote:
>>On Wed, Apr 11, 2012 at 05:46:41PM -0400, Christos Zoulas wrote:
>>> On Apr 2,  1:50pm, prlw1%cam.ac.uk@localhost (Patrick Welche) wrote:
>>> -- Subject: Re: gdb + sigtraps
>>> 
>>> | On run, they both receive a SIGTRAP
>>> | After c, the amd64 gets another SIGRAP, but the i386 apparently runs
>>> | "RXl+", but dig consumes over 80% of one the cpus.  DiG 9.9.0a1 is never
>>> | printed. dig simply consumes cpu cycles. ctrl-C in an attempt to see
>>> | what dig is doing just prints "^C". kill -HUP the dig process then
>>> | shows (well, from the beginning on the i386):
>>> 
>>> Try it now...
>>
>>Just to check, what I need are:
>>
>>  inf-ptrace.c  1.5
>>  nbsd-thread.c 1.15
>>
>>?
>>
>>
>>The gdb `which dig`, break main, run, next, example hasn't changed for me.
>>The gtk programme (dasher) example is much better: everything runs until
>>the break point is reached (eg gdb dasher, break sendText, run -a direct),
>>but then I still can't "next" to the next line of code, so it behaves in
>>the same way as the dig example.
>>
>>gdb `which dig`:
>>Reading symbols from /usr/bin/dig...(no debugging symbols found)...done.
>>(gdb) break main
>>Breakpoint 1 at 0x408b59
>>(gdb) run
>>Starting program: /usr/bin/dig 
>>[Switching to LWP 1]
>>
>>Breakpoint 1, 0x0000000000408b59 in main ()
>>(gdb) n
>>Single stepping until exit from function main,
>>which has no line number information.
>>[New LWP 4]
>>
>>Program received signal SIGTRAP, Trace/breakpoint trap.
>>[Switching to LWP 4]
>>0x00007f7ff58391ca in _sys___kevent50 () from /usr/lib/libc.so.12
>>(gdb) 
>>Single stepping until exit from function _sys___kevent50,
>>which has no line number information.
>>0x00007f7ff6005d81 in __kevent50 () from /usr/lib/libpthread.so.1
>>(gdb) 
>>Single stepping until exit from function __kevent50,
>>which has no line number information.
>>0x00007f7ff641d7b9 in ?? () from /usr/lib/libisc.so.5
>>(gdb) 
>>Cannot find bounds of current function
>>(gdb) 
>>Cannot find bounds of current function
>>
>>
>>Is there any way I can help?
>
>Don't know. I see the same, I'll look into it.

I just put a fix in that makes your example work.

christos