TARGET_SIGNAL_TRAP

TARGET_SIGNAL_TRAP

[David Carlton]

Some users here have noted that they have a hard time debugging
multithreaded code in GDB.  We're assuming that it's probably a bug in
our code instead of in GDB: it's just that GDB is changing the timing
of the threads in ways that expose a latent bug in our code.

Which made me curious: why does GDB change the timing of programs?  I
set a breakpoint in handle_inferior_event, and I see all these events
claiming to be TARGET_SIGNAL_TRAPs.  But I haven't set any breakpoints
or watchpoints!  So what causes all these traps to be generated?  Or
am I misunderstanding the situation?  (I'm not at all sure that this
is specific to multithreaded code - it may just be that its effects
are most pronounced for multithreaded code, because single-threaded
code doesn't have as much timing to be thrown off.)

David Carlton
carlton@kealia.com

Re: TARGET_SIGNAL_TRAP

[Daniel Jacobowitz]

On Thu, Jul 17, 2003 at 11:29:44AM -0700, David Carlton wrote:
> Some users here have noted that they have a hard time debugging
> multithreaded code in GDB.  We're assuming that it's probably a bug in
> our code instead of in GDB: it's just that GDB is changing the timing
> of the threads in ways that expose a latent bug in our code.
> 
> Which made me curious: why does GDB change the timing of programs?  I
> set a breakpoint in handle_inferior_event, and I see all these events
> claiming to be TARGET_SIGNAL_TRAPs.  But I haven't set any breakpoints
> or watchpoints!  So what causes all these traps to be generated?  Or
> am I misunderstanding the situation?  (I'm not at all sure that this
> is specific to multithreaded code - it may just be that its effects
> are most pronounced for multithreaded code, because single-threaded
> code doesn't have as much timing to be thrown off.)

Every time that a breakpoint is hit, including one breakpoint set at
every shared library load/unload, thread creation, or sometimes thread
exit, all threads are stopped and restarted.  That's the usual cause.

Signals also stop the process.  If GDB isn't going to report the signal
then it doesn't stop all threads, but that does interfere with timing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: TARGET_SIGNAL_TRAP

[David Carlton]

On Thu, 17 Jul 2003 14:32:14 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> Every time that a breakpoint is hit, including one breakpoint set at
> every shared library load/unload, thread creation, or sometimes thread
> exit, all threads are stopped and restarted.  That's the usual cause.

> Signals also stop the process.  If GDB isn't going to report the signal
> then it doesn't stop all threads, but that does interfere with timing.

Ah, thanks for the info.  I wonder if it's the shared library loads
that we're seeing.  Hmm: we might even be able to control that one.

David Carlton
carlton@kealia.com

Re: TARGET_SIGNAL_TRAP

[Elena Zannoni]

David Carlton writes:
 > On Thu, 17 Jul 2003 14:32:14 -0400, Daniel Jacobowitz <drow@mvista.com> said:
 > 
 > > Every time that a breakpoint is hit, including one breakpoint set at
 > > every shared library load/unload, thread creation, or sometimes thread
 > > exit, all threads are stopped and restarted.  That's the usual cause.
 > 
 > > Signals also stop the process.  If GDB isn't going to report the signal
 > > then it doesn't stop all threads, but that does interfere with timing.
 > 
 > Ah, thanks for the info.  I wonder if it's the shared library loads
 > that we're seeing.  Hmm: we might even be able to control that one.
 > 
 > David Carlton
 > carlton@kealia.com


try 'maint info break' to see all (kind of) the hidden breakpoints.

elena