Red Hat Bugzilla – Bug 209445
gdb hangs after stopping multithreaded application
Last modified: 2007-11-30 17:11:45 EST
Description of problem:
Debugging multithreaded application with GDB. Stop application and gdb reports
Cannot fetch general-purpose registers for thread 130096048L generic error.
Attempt to run, load a new file, or quit results in gdb hang.
Version-Release number of selected component (if applicable):
Fedora Core 4: gdb 6.3.0, gcc 4.0.2
Fedora Core 5: gdb 6.3.0, gcc 4.1.1
Every time I try to quit debugging my program.
Steps to Reproduce:
1. start gdb with my program
2. run the program
3. quit program
gdb can not restart program or quit.
Ability to restart program, reload it, or quit gdb
Additional info: Program is using glib2
As FC5 gdb generally works with threads I feel more reproducibility info would
Could you please try the RawHide/FC6 gdb instead?
It has been rebased on 6.5 and it has improved the threads supports a lot:
rpmbuild --rebuild gdb-6.5-8.fc6.src.rpm
rpm -U /usr/src/redhat/RPMS/i386/gdb-6.5-8.fc6.i386.rpm
On my FC5 box, I tried the updated GDB from FC6 beta (reported as 6.5-rh when it
starts). I have the same result, however the error message now reads:
Couldn't get registers: No such process.
It would be useful to get your application for test.
I could not reproduce it, for example on Ekiga with 13 threads.
In some cases I could reproduce gdb lockup on its quit; it is better to quit
gdb(1) for a next debugging session, still I understand it should get fixed.
The application is for in-house use and can't be released. I can only provide a
bit of info, but it has over 50 threads, one talking to a postgresql server, one
running a gsoap server, and all controlled by glib2 (they are gthreads using
glib message passing). I did add a call to wait on all threads to quit, then
sleep(3), then exit. That seemed to let my program quit gracefully in the
debugger. My concern is that I have some memory leak somewhere that is messing
up GDB, which GDB **should** handle. (I also plan on using efence, etc. to
check the application.) Any suggestions? Wish I could provide more.
Created attachment 137859 [details]
Reproducibility for FC6(RawHide) / gdb-6.5-8.fc6.i386 / kernel-2.6.18-1.2693.fc6.i686
Lockup od gdb on exit has been confirmed, not yet fixed but I do not ask about
Efence use is very simple, I hope you are aware of it:
Valgrind should be generally more effective, but in fact I was always more
depending on efence myself.
Any memory leak should never mess GDB, I did not much understand why it should
be a problem.
Problem reproduced here but it looks to me as a rare race - does your
application really create/delete the threads all the time?
Thanks for the bugreport, sure to be fixed.
Created attachment 137861 [details]
Reproducibility for FC6(RawHide) / gdb-6.5-8.fc6.i386 / kernel-2.6.18-1.2693.fc6.i686 (fixed)
My application only creates the threads at startup. I think what could be
happening is on cleanup/termination. My code is terminating the 50+ threads
(joining each of them) and then quickly terminating the application. That could
be triggering a problem like the race you describe. It would also explain why
adding a sleep before exiting the application seemed fixed the problem.
I tried a quick and dirty glib application but can't duplicate the problem at
this time. I'll try your code first of the week.
i'm running into this issue while i'm testing firefox's totem plugin. It is very
easily reproducible (running lastest RawHide/i386). Things to reproduce:
1. Firefox with Totem plugin
2. some test videos ( i used those free Theora videos from
3. run firefox, attach to it from gdb, and see some short videos. after 4-6
videos usually firefox freezes, with gdb reporting the error
* Mon Feb 5 2007 Jan Kratochvil <firstname.lastname@example.org> - 6.6-3
- Fix a race during attaching to dying threads; backport (BZ 209445).