Bug 9565 - when debugging threaded applications you get extra SIGTRAPs
when debugging threaded applications you get extra SIGTRAPs
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
6.2
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-18 12:24 EST by Christopher Blizzard
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-25 23:14:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 12:25 EST, Christopher Blizzard
no flags Details

  None (edit)
Description Christopher Blizzard 2000-02-18 12:24:40 EST
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 12:25:59 EST
Created attachment 123 [details]
test case
Comment 2 Christopher Blizzard 2000-03-02 12:24:59 EST
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 10:53:59 EDT
assign to jakub
Comment 4 Christopher Blizzard 2000-05-22 16:00:59 EDT
This has been fixed in the pre 5.0 snapshots, just FYI.
Comment 5 dyp 2000-05-25 23:12:59 EDT
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-25 23:14:59 EDT
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 10:06:53 EDT
These seemed to be fixed in our current tree...
Comment 8 Christopher Blizzard 2000-07-26 10:46:43 EDT
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.