This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Patch for non-stop remote assertion (was: RE: [patch] Support inferior events in python)
- From: Marc Khouzam <marc dot khouzam at ericsson dot com>
- To: "'sami wagiaalla'" <swagiaal at redhat dot com>, "'Tom Tromey'" <tromey at redhat dot com>, "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Wed, 20 Apr 2011 16:26:35 -0400
- Subject: Patch for non-stop remote assertion (was: RE: [patch] Support inferior events in python)
- References: <4D4C62FA.5080101@redhat.com>
> -----Original Message-----
> From: sami wagiaalla [mailto:swagiaal@redhat.com]
> Sent: Friday, February 04, 2011 3:35 PM
> To: Tom Tromey
> Cc: gdb-patches@sourceware.org
> Subject: Re: [patch] Support inferior events in python
>
>
> > Sami> +2011-01-21 Sami Wagiaalla<swagiaal@redhat.com>
> > Sami> + Oguz Kayral<oguzkayral@gmail.com>
> >
> > This is ok. Thanks for persevering, and congratulations.
> >
> > Tom
>
> Woho! :).. Thank you for all the guidance. Committing soon.
Hi,
I think I'm having trouble with this patch.
With non-stop and extended-remote, I can no longer
attach to a process. I get an assertion in the python
part.
What I think is happening is the following.
In remote_notice_new_inferior() line 1527 of remote.c,
we find out for the first time about a thread on the remote.
The call to remote_add_thread() will add this thread
but will also trigger the notifications about a running
thread. Still within remote_notice_new_inferior(), the
very next line, inferior_ptid is updated to match the
new thread. It seems to be too late though. When
the python code receives the notification of a thread
resume, it uses the old inferior_ptid to find the arch
and the assertion is triggered because inferior_ptid does
not have the tid yet.
One fix that seems to work is to update the inferior_ptid
before calling remote_add_thread(). But I have no idea
if this is safe or not (it does not cause any regressions).
I posted the patch at the end of this mail.
The stack trace of the assertion and and very simple
example session below.
#0 0xb786e422 in __kernel_vsyscall ()
#1 0xb7417651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb741aa82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0809d915 in dump_core () at ../../src/gdb/utils.c:1053
#4 0x0809dbd5 in internal_vproblem (problem=0x847da54, file=0x83bf29a "../../src/gdb/thread.c", line=620,
fmt=0x83bf27c "%s: Assertion `%s' failed.", ap=0xbfaffc2c "\001\373;\b\227\362;\b") at ../../src/gdb/utils.c:1211
#5 0x0809dc31 in internal_verror (file=0x83bf29a "../../src/gdb/thread.c", line=620, fmt=0x83bf27c "%s: Assertion `%s' failed.",
ap=0xbfaffc2c "\001\373;\b\227\362;\b") at ../../src/gdb/utils.c:1236
#6 0x0809dc69 in internal_error (file=0x83bf29a "../../src/gdb/thread.c", line=620, string=0x83bf27c "%s: Assertion `%s' failed.")
at ../../src/gdb/utils.c:1246
#7 0x081b79b6 in is_thread_state (ptid=..., state=THREAD_EXITED) at ../../src/gdb/thread.c:620
#8 0x081b7a17 in is_exited (ptid=...) at ../../src/gdb/thread.c:633
#9 0x080a5143 in has_stack_frames () at ../../src/gdb/frame.c:1336
#10 0x081ce2f4 in get_current_arch () at ../../src/gdb/arch-utils.c:757
#11 0x08132b48 in python_on_resume (ptid=...) at ../../src/gdb/python/py-inferior.c:103
#12 0x0809780b in observer_target_resumed_notification_stub (data=0x8132b36, args_data=0xbfaffd74) at ./observer.inc:423
#13 0x080970a0 in generic_observer_notify (subject=0x948f4e0, args=0xbfaffd74) at ../../src/gdb/observer.c:168
#14 0x08097895 in observer_notify_target_resumed (ptid=...) at ./observer.inc:448
#15 0x081b7951 in set_running (ptid=..., running=1) at ../../src/gdb/thread.c:610
#16 0x080e80ad in remote_add_thread (ptid=..., running=1) at ../../src/gdb/remote.c:1487
#17 0x080e8232 in remote_notice_new_inferior (currthread=..., running=1) at ../../src/gdb/remote.c:1527
#18 0x080ea041 in remote_threads_info (ops=0x848a7e0) at ../../src/gdb/remote.c:2668
#19 0x080ecb10 in extended_remote_attach_1 (target=0x848a7e0, args=0x944cdff "13303", from_tty=0) at ../../src/gdb/remote.c:4243
#20 0x080ecd7a in extended_remote_attach (ops=0x848a7e0, args=0x944cdff "13303", from_tty=0) at ../../src/gdb/remote.c:4299
#21 0x081e02d0 in target_attach (args=0x944cdff "13303", from_tty=0) at ../../src/gdb/target.c:3256
#22 0x081a3ea1 in attach_command (args=0x944cdff "13303", from_tty=0) at ../../src/gdb/infcmd.c:2475
Session to reproduce:
> gdb.7.4
GNU gdb (GDB) 7.3.50.20110417-cvs
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) target extended-remote :9999
Remote debugging using :9999
(gdb) attach 10283
Attached to process 10283
[New Thread 10283.10283]
../../src/gdb/thread.c:620: internal-error: is_thread_state: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Potential fix that causes no regressions.
What do you think?
The problem is in HEAD and 7_3 so a fix should go into both.
2011-04-19 Marc Khouzam <marc.khouzam@ericsson.com>
* remote.c (remote_notice_new_inferior): Update the
inferior_ptid before calling remote_add_thread.
### Eclipse Workspace Patch 1.0
#P src
Index: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.443
diff -u -r1.443 remote.c
--- gdb/remote.c 20 Apr 2011 17:54:08 -0000 1.443
+++ gdb/remote.c 20 Apr 2011 20:15:19 -0000
@@ -1524,8 +1524,11 @@
thread_change_ptid (inferior_ptid, currthread);
else
{
- remote_add_thread (currthread, running);
+ /* First update the inferior_ptid as it could
+ be used within the call to remote_add_thread
+ which triggers observer notifications */
inferior_ptid = currthread;
+ remote_add_thread (currthread, running);
}
return;
}