Unable to detect multiple threads

[Ritesh Kapoor]

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 <address@hidden>.


/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