Re: [rfc] Fix removing breakpoint from shared library race

["Ulrich Weigand" <uweigand@de.ibm.com>]

Joel Brobecker wrote:

> > When *removing* breakpoints, however, there is no such check.  I have a
> > multi-threaded test case that reproducibly runs into an error when trying
> > to remove a breakpoint from a shared library that was *just* unloaded.
> [...]
> > Am I missing some reason why we shouldn't get to this point?  Otherwise,
> > this seems a reasonble solution to me ...
> 
> The fix looks reasonable to me, but I'm not sure, though. Perhaps
> part of the problem is that I don't see how you got there in your
> example (I'm having trouble figuring out a case where the debugger
> would end up removing a breakpoint while a shared library has just
> been unloaded). Could you post more details?

The actual test case was using the Cell multi-arch debugger.  However,
I think the problem can potentially also show up in current GDB with
multi-threaded code.

Assume you have a thread A that is just unloading a shared library

 1.) app calls dlclose
 2.) dlclose unmaps shared library
 3.) dlclose calls _dl_debug_event (which GDB has a breakpoint on)
 4.) GDB gets active
 5.) GDB processes the unload event

while at the same time, thread B is doing something that invokes GDB

 A.) app runs into a breakpoint
 B.) GDB gets active
 C.) GDB stops all threads
 D.) GDB removes all breakpoints
 E.) GDB goes to user prompt

(Note that this still assumes all-stop, breakpoints-not-always-inserted
mode.  If those new modes are active, the race would probably be more
difficult to trigger.)

Now imagine the race where thread A is just in-between steps 2.) and 3.)
while thread B runs into the breakpoint (which causes GDB to stop thread
A at this point).  When GDB now performs action D.), the breakpoints that
were inserted into the shared library are still on GDB's list as active,
because step 5.) which would have set them to solib_disabled state did
not yet run.  However, attempting to remove the breakpoint will fail 
because the library was already unmapped.

This is the situation that my patch attempts to address, by having the
remove_breakpoints not fail.  At some later point, either when GDB actually
gets to process the solib event, or when GDB tries to re-insert the
breakpoints, GDB will properly recognize that the library has been 
unloaded and sets the state to solib_disabled.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com