Bug 13869 - Latest gdb 7.4 (CVS HEAD) has problem with "target async": Cannot get thread event message: debugger service failed
Summary: Latest gdb 7.4 (CVS HEAD) has problem with "target async": Cannot get thread ...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: threads (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-19 21:06 UTC by Thomas Mittelstaedt
Modified: 2015-12-17 15:44 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Mittelstaedt 2012-03-19 21:06:55 UTC 
Just updated via cvs to the latest gdb 7.4 code and - as in a couple of previous tries - gdb seems to have a problem when I run my custom build of evolution 
in target async mode.

The following is in my .gdbinit:
set target-async 1
set non-stop on

Then I usually run it via gdb -x ../.gdbinit appname.

gdb hangs with the "Cannot get thread event message: debugger service failed"
message. gdb 7.3 has no problems with that.
I run an ubuntu linux, version 9.10 karmic, Linux linux1 2.6.31-23-generic #75-Ubuntu SMP Fri Mar 18 18:08:39 UTC 2011 i686 GNU/Linux.

Without the above target-async, gdb starts the app okay.
Comment 1 Yao Qi 2012-05-23 07:29:33 UTC 
I can reproduce this problem on CVS trunk with existing test case gdb.thread/manythreads.c

  $ ./gdb -ex "set target-async on" -ex "set non-stop on" -ex "run" ./testsuite/gdb.threads/manythreads

  ...
  Thread <255> executing
  [Thread 0xb77feb70 (LWP 12986) exited]
  [New Thread 0xb77feb70 (LWP 12987)]
  Cannot get thread event message: debugger service failed
  (gdb) (gdb) quit

Initial analysis shows that this problem is caused by the race condition between gdb (with libthread_db) and inferior (with libpthreads.so) on accessing some shared state variables, such as __nptl_last_event.  The code in nptl to access shared state variables is written in a thread-safe way (using some atomic and compare-and-swap operations), however, GDB doesn't coordinate with inferior on accessing them.  The fix would be `stopping all threads in inferior when gdb tries to access state variables in thread library in async & non-stop mode'.

I'll post a patch to @gdb-patches in two or three days.
Comment 2 Axel Müller 2013-02-28 14:06:38 UTC 
(In reply to comment #1)
> I'll post a patch to @gdb-patches in two or three days.
Any news on this? Two or three days have past :-)
Comment 3 Yao Qi 2013-02-28 14:13:23 UTC 
(In reply to comment #2)
> (In reply to comment #1)
> > I'll post a patch to @gdb-patches in two or three days.
> Any news on this? Two or three days have past :-)

No much progress on it.  I had a patch, but it caused some regressions.  I don't have much time recently to look into it.  Any one interested in it, feel free to take this bug over.
Comment 4 Marc-Andre Laperle 2014-04-05 01:26:23 UTC 
I have the same issue debugging Eclipse on Ubuntu 13.10 32 bit with GDB 7.6.1.
Comment 5 Pedro Alves 2015-12-17 15:44:48 UTC 
This was fixed a while ago.  GDB no longer uses libthread_db thread events or walks its data structures when listing threads.