[Bug cli/13728] GDB crashes on catch exec -> detach

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.