Summary: | remote debugging a multithreaded application with gdb creates a SIGTRAP | ||
---|---|---|---|
Product: | gdb | Reporter: | kraj |
Component: | threads | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | emilio.riva, gdb-prs, m.cavallini, pedro, signorelli |
Priority: | P3 | ||
Version: | unknown | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | test.c |
Description
kraj
2005-02-02 04:18:00 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. 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. 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 ===================================================== 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 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. I'm hitting the same problem. Anybody knows if this problem is close to be fixed yet? 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. |