Re: gdb + sigtraps

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

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)

Cheers,

Patrick