Bug 9565

Summary: when debugging threaded applications you get extra SIGTRAPs
Product: [Retired] Red Hat Linux Reporter: Christopher Blizzard <blizzard>
Component: gdbAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 6.2CC: bryner, dyp, gafton, redhat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-05-26 03:14:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test case none

Description Christopher Blizzard 2000-02-18 17:24:40 UTC 
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);
Comment 1 Christopher Blizzard 2000-02-18 17:25:59 UTC 
Created attachment 123 [details]
test case
Comment 2 Christopher Blizzard 2000-03-02 17:24:59 UTC 
The beginning of this bug says that you have to have the patch applied in
another bug.  That's not actually the case.  You can do it with:

glibc-2.1.3-15
gdb-4.18-10

which is what I have installed on my laptop.
Comment 3 Cristian Gafton 2000-05-22 14:53:59 UTC 
assign to jakub
Comment 4 Christopher Blizzard 2000-05-22 20:00:59 UTC 
This has been fixed in the pre 5.0 snapshots, just FYI.
Comment 5 dyp 2000-05-26 03:12:59 UTC 
About the last comment from 05/22/00. It looks
like this is not the case. I use official
5.0 release.

[New Thread 2049 (runnable)]
[New Thread 1026 (runnable)]
[New Thread 2051 (runnable)]

<Here I exit the thread>

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 2051 (runnable)]
0x0 in ?? ()
Current language:  auto; currently c
Comment 6 Christopher Blizzard 2000-05-26 03:14:59 UTC 
It's a seperate problem, really.  Here's a url describing the problem:

http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00525.html
Comment 7 Trond Eivind Glomsrxd 2000-07-26 14:06:53 UTC 
These seemed to be fixed in our current tree...
Comment 8 Christopher Blizzard 2000-07-26 14:46:43 UTC 
Unless a thread exits.  Try that.  It should explode.