Description of Problem: How Reproducible: Very Steps to Reproduce: 0. Enter myscript.py as below 1. gdb python 2. run myscript.py 3. ^C during program 4. 'info threads' Actual Results: No threads there to manipulate. Expected Results: Threads there to manipulate. Additional Information: Also stops on SIG32, which according to Matt should be passed right through. myscript.py: #!/usr/bin/python import thread import signal signal.signal(signal.SIGINT, signal.SIG_DFL) def athread(): print "new thread" while 1: signal.pause() thread.start_new_thread(athread, ()) print "old thread" while 1: signal.pause()
Seems to work for me... gdb-5.0rh-8 (gdb) run myscript.py Starting program: /usr/bin/python myscript.py [New Thread 1024 (LWP 27018)] [New Thread 2049 (LWP 27027)] [New Thread 1026 (LWP 27028)] old thread new thread Program received signal SIGINT, Interrupt. [Switching to Thread 1026 (LWP 27028)] 0x40126587 in __libc_pause () from /lib/i686/libc.so.6 (gdb) info threads * 3 Thread 1026 (LWP 27028) 0x40126587 in __libc_pause () from /lib/i686/libc.so.6 2 Thread 2049 (LWP 27027) 0x4014ae37 in __poll (fds=0x80d1614, nfds=1, timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63 1 Thread 1024 (LWP 27018) 0x40126587 in __libc_pause () from /lib/i686/libc.so.6 (gdb)
To clarify the problem: . I had not been using the rawhide gdb, which fixes a number of thread related issues. Upgrading made things partially better. . The rawhide gdb doesn't work with the 2.2.x kernels, which the machine I was on runs. This is a WONTFIX thing - it's caused by the usage of 2.4 kernel headers when compiling glibc, IIRC.