When debugging applications that happen to be using threads in gdb
sometimes you can get a SIGTRAP and the program being debugged goes into a
tailspin.  Attached is a program that shows the problem with instructions
on how to reproduce it.  Also, to reproduce it you must have the patch
that's in bug #9373.

[blizzard@gunhead thread_test]$ gdb test
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b main
Breakpoint 1 at 0x80485e6: file test.c, line 15.
(gdb) r
Starting program: /home/blizzard/src/thread_test/test

Breakpoint 1, main (argc=1, argv=0xbffff9e4) at test.c:15
15        pthread_mutex_init(&global_lock, NULL);
(gdb) handle SIG32 nostop noprint
Signal        Stop      Print   Pass to program Description
SIG32         No        No      Yes             Real-time event 32
(gdb) b pthread_mutex_lock
Breakpoint 2 at 0x400207c6: file mutex.c, line 79.
(gdb) c
Continuing.

Breakpoint 2, 0x400207c6 in __pthread_mutex_lock (mutex=0x40029954)
    at mutex.c:79
79      {
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x4004bdeb in __sigsuspend (set=0xbffff800)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
48            int result = INLINE_SYSCALL (rt_sigsuspend, 2, set, _NSI /
8);