Hi, I'm facing a weird problem with gdb.
Scenario 1 --- I write a small application which creates a thread and compile it as - > g++ -o thread thread.cpp -pthread Now I am able to debug the 'thread' application as - > gdb thread GNU gdb 6.3 Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) b thread_function Breakpoint 1 at 0x8048e72: file thread.cpp, line 22. (gdb) run Starting program: /delsoft/rkapoor/mywork/thread [Thread debugging using libthread_db enabled] [New Thread -1218568064 (LWP 12674)] [Switching to Thread -1218568064 (LWP 12674)] Breakpoint 1, thread_function() at thread.cpp:22 This works as expected. Scenario 2 --- If I put the same thread creation code in my production application i am unable to debug it. When running gdb as - > gdb production I get the following initialization message from gdb - GNU gdb 6.3 Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Followed by placing a breakpoint on the function to be executed on the new thread - > b thread_function I get this message - Detaching after fork from child process 12662. Detaching after fork from child process 12663. Detaching after fork from child process 12666. Program received signal SIG32, Real-time event 32. Stop for GDB Program terminated with signal SIGKILL, Killed. The program no longer exists. The application runs as expected without gdb but when debugging it recieves a SIGKILL if I place a breakpoint on the function that is to be executed on the new thread. I've checked the libc and libpthread versions - /lib/tls/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3 20030502 (Red Hat Linux 3.2.3-20). Compiled on a Linux 2.4.20 system on 2003-10-02. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others NPTL 0.60 by Ulrich Drepper RT using linux kernel aio The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton Thread-local storage support included. Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>. /lib/tls/libpthread.so.0 NPTL 0.60 by Ulrich Drepper Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Forced unwind support included. If I run the application using gdb and don't place a breakpoint on the any function which will be executed on the new thread, then also it runs fine. However the 'systag' generated by gdb whenever it detects a new thread isn't displayed. Please let me know if you have faced a similar problem. Thanks, Ritesh _______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb