Bug 9565 - when debugging threaded applications you get extra SIGTRAPs
Summary: when debugging threaded applications you get extra SIGTRAPs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb   
(Show other bugs)
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-18 17:24 UTC by Christopher Blizzard
Modified: 2008-05-01 15:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-26 03:14:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test case (1.04 KB, text/plain)
2000-02-18 17:25 UTC, Christopher Blizzard
no flags Details

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
welcome to change it and/or distribute copies of it under certain
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

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

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 /

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:


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:


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.

Note You need to log in before you can comment on or make changes to this bug.