Bug 8963 - remote debugging a multithreaded application with gdb creates a SIGTRAP
Summary: remote debugging a multithreaded application with gdb creates a SIGTRAP
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: threads (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-02 04:18 UTC by kraj
Modified: 2015-12-17 16:38 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
test.c (406 bytes, text/plain)
, kraj
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kraj 2005-02-02 04:18:00 UTC
[Converted from Gnats 1858]

The attached program can not be debugged because of following error
=======================================
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.

on gdbserver I get the following error.
=======================================
Child terminated with signal = 5

Child terminated with signal = 0x5
GDBserver exiting

======================================

however if I dont set breakpoints and just run as such then the program runs fine and exits are OK.

Release:
unknown

Environment:
native build on i686

How-To-Repeat:
compile the attached file
gcc -pthread test.c -g -O0

run gdbserver

gdbserver localhost:1234 a.out

run gdb 

gdb a.out

(gdb) target remote localhost:1234 
(gdb) b main
(gdb) r
(gdb) b sleeping
(gdb) c
Comment 1 emilio.riva 2005-10-03 06:23:14 UTC
From: "Emilio Riva" <emilio.riva@marconi.com>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: threads/1858: remote debugging a multithreaded application with gdb
 creates a SIGTRAP
Date: Mon, 3 Oct 2005 08:23:14 +0200

 I got the same problem in both PPC and i686 architecture; gdb/gdbserver 6.3
 with no patches. It seems related to NPTL/linuxthread differences:
 breakpoints works only on the main thread.
 
 

Comment 2 signorelli 2005-11-04 08:33:25 UTC
From: signorelli@gefran.com
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: threads/1858: remote debugging a multithreaded application with gdb
 creates a SIGTRAP
Date: Fri, 4 Nov 2005 09:33:25 +0100

 I've the same problem trying to debug an RTAI/fusion remote application
 from Windows, with ecplise + cygwin.
 Inserting a breakpoint in a RTAI task breaks the execution with signal 5.
 
 Note: remote debug of normal applications (no rtai space) works fine.
 

Comment 3 m.cavallini 2005-11-04 09:46:09 UTC
From: "Marco Cavallini [KOAN]" <m.cavallini@koansoftware.com>
To: <gdb-gnats@sources.redhat.com>
Cc:  
Subject: Re: threads/1858: remote debugging a multithreaded application with gdb creates a SIGTRAP
Date: Fri, 4 Nov 2005 10:46:09 +0100

 I tried the same example you provided here (test.c)
 and with the following commands it run perfectly
 managing the breakpoint into function sleeping().
 
 I used a test program under Klinux + RTAI/fusion
 having the same behavior, this is a known issue in RTAI/fusion
 bypassed starting the program with 'c' (continue) instead of 'r' (run)
 
 run gdbserver
 
 gdbserver localhost:1234 a.out
 
 run gdb 
 
 gdb a.out
 
 (gdb) target remote localhost:1234 
 (gdb) b sleeping
 (gdb) c 
 
 it works !
 HTH
 
 =====================================================
 Marco Cavallini
 Koan s.a.s. - Software Engineering
 Linux and WinCE solutions for Embedded and Real-Time Software
 http://www.koansoftware.com  -  http://www.klinux.org
 =====================================================
Comment 4 hypo 2009-03-25 06:33:18 UTC
i still see this on ubuntu 8.10. test.c still gives sigtrap when breakpoint is
set on sleeping().

Host:
----

Ubuntu 8.10
$ uname -a
Linux homer-slaver 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686
GNU/Linux

$ arm-linux-gdb --version
GNU gdb 6.4
Copyright 2005 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 "--host=i386-pc-linux-gnu
--target=arm-linux-uclibcgnueabi".


$ arm-linux-gcc --version
arm-linux-gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.

Target: arm v5 (gumstix verdex xlp6 running buildroot) (arm-linux-uclibcgnueabi)
-------
[root@gumstix ~]# uname -a
Linux gumstix 2.6.21gum #1 Sun Dec 21 16:37:58 PST 2008 armv5tel unknown

Comment 5 teawater 2009-03-25 07:13:49 UTC
http://sourceware.org/gdb/wiki/FAQ

GDB does not see any threads besides the one in which crash occurred; or SIGTRAP
kills my program when I set a breakpoint.

    * This frequently happen on Linux, especially on embedded targets. There are
two common causes:
          o

            you are using glibc, and you have stripped libpthread.so.0
          o

            mismatch between libpthread.so.0 and libthread_db.so.1 

      GDB itself does not know how to decode "thread control blocks" maintained
by glibc and considered to be glibc private implementation detail. It uses
libhread_db.so.1 (part of glibc) to help it do so. Therefore, libthread_db.so.1
and libpthread.so.0 must match in version and compilation flags.

      In addition, libthread_db.so.1 requires certain non-global symbols to be
present in libpthread.so.0.

      Solution: use strip --strip-debug libpthread.so.0 instead of strip
libpthread.so.0. 
Comment 6 Hin Lam 2010-02-27 05:49:29 UTC
I'm hitting the same problem.  Anybody knows if this problem is close to be fixed yet?
Comment 7 Pedro Alves 2015-12-17 16:38:04 UTC
This works for me.  It very much sounds like the FAQ Teawater pointed at.  I'm tentatively closing as fixed.  Feel free to reopen if you can still reproduce it with current gdb.