This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug cli/13728] GDB crashes on catch exec -> detach
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 14 Mar 2012 15:20:17 +0000
- Subject: [Bug cli/13728] GDB crashes on catch exec -> detach
- Auto-submitted: auto-generated
- References: <bug-13728-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13728
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #3 from Pedro Alves <palves at redhat dot com> 2012-03-14 15:20:17 UTC ---
Yeah.
This made me question whether we really want to continue processing the
commands if the thread that hit the breakpoint is gone
(detach/disconnect/kill/etc.). We similarly stop processing if the target is
proceeded, which made me wonder about doing the same here, but in proceed case,
we have extra complications, for example, related to ending up with more than
one bpstat active for the same thread. So if we can make this work, it seems
like we should try.
Does that patch even run "valgrind free" ? It seems like you'd restore the
bpstat into:
inferior_thread ()->control.stop_bpstat
But that thread has been deleted/free'd, along with its stop_bpstat.
If we remove the bpstat temporarily out of the thread, as in:
/* This pointer will iterate over the list of bpstat's. */
bs = *bsp;
+ *bsp = NULL;
Then if something in the command list deletes a breakpoint that was in the
bpstat, bpstat_remove_breakpoint_callback will not be able to find the bpstat,
and we will end up a stale breakpoint pointer in the bpstat.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.