Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gdb + sigtraps


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
now I will get sigtraps, keep continuing until my break point is reached
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?

AFAICT this happens only with programs using multithreading.  Somehow
gdb gets confused by the traps (single step and/or breakpoint) that it
itself triggers in the debuggee.

Actually, debugging multithreaded programs using gdb doesn't work as
expected since at least November 2007, when the pthread structure grew
a member in front of pt_magic, while the pthread_dbg library wasn't
adapted to that change.  And in the meantime, it grew another member.
I fixed that already in my own tree, but while helping a bit, this
isn't enough to make gdb work reliably again on multithreaded programs.
I'm investigating this further.

I am not sure about the purpose of the pthread_dbg library anyway.
On one side it is way to intertwined with gdb internals to allow
for adaption to another debugger.  If on the other side the placement
of libpthread_dbg alongside libpthread in our source tree was to
encourage anyone changing libpthread to also do the accompanying
changes to libpthread_dbg, this obviously didn't work out.  Or was
this simply separated from gdb sources due to license reasons?

--                         Wolfgang Solfrank

Home | Main Index | Thread Index | Old Index