Re: gdb + sigtraps

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

In article <20120321162135.GY14996%quartz.inf.phy.cam.ac.uk@localhost>,
Patrick Welche  <prlw1%cam.ac.uk@localhost> wrote:
>On Tue, Mar 20, 2012 at 01:03:39PM +0000, Christos Zoulas wrote:
>> In article <201203192317.q2JNHgWW016757%ginseng.pulsar-zone.net@localhost>,
>> Matthew Mondor  <mm_lists%pulsar-zone.net@localhost> wrote:
>> >On Mon, 19 Mar 2012 18:02:28 +0000
>> >Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
>> >
>> >> When trying to debug my favorite program dasher on -current/amd64 using
>> >> gdb, I keep getting sigtraps. This makes life difficult, but seems to be
>> >> "recent". e.g.,
>> >> gdb dasher
>> >> break sendText
>> >> c
>> >> now I will get sigtraps, keep continuing until my break point is reached
>> >> s
>> >> and we are back to sigtraps and I can't step to the next line...
>> >> This isn't what used to happen...
>> >> 
>> >> Any ideas where to look?
>> >
>> >I think that I've also got this when debugging a particular program on
>> >netbsd-6/amd64 (I forgot which at the moment though), and of course if
>> >telling gdb to ignore it, it'd just be stuck...
>> 
>> The problem is that the internal breakpoint trap that is being inserted
>> by gdb to rtld to catch when a library is loaded, is not treated as internal
>> and it causes a breakpoint to the user. This breakpoint is used to recognize
>> when libpthread is loaded for example, so that the debugger can switch to
>> multi-threaded mode. As far as libpthread_dbg is concerned, this provides
>> a sanctioned way to look at the internals of the pthread library without
>> exposing the guts to the debugger. This is what the tdb_ abstraction is for.
>> I think we should keep it.
>
>So what can I do to debug my program now? (It uses gtk -> gtk_main() -> 
>threads)

continue does not work? Or telling gdb to ignore SIGTRAP? Made some more
progress debugging it, but gdb is a complex beast...

christos