[lldb-dev] Race condition crashes during launching LLDB

[Jeffrey Tan via lldb-dev]

Thanks Pavel, yeah, that's what I figured out yesterday.
In "So now Destroy starts destroying the process while it is just being
*started up* and things go south", for "started up", I assume you mean
inferior is not *continued/resumed* from first entry point breakpoint,
right? The inferior is definitely started and hitting the first entry point
breakpoint because of the first "wait_for_process_stop()" call. Just want
to confirm we are on the same page.

I have revised my sample code to use two thread.Event to synchronize
running/stopping between main thread and listener thread, the race
condition seems to go away after running it 10 times in a loop. I will
integrate this logic into our unit test to see if it fixed the race crash.


On Fri, Feb 5, 2016 at 1:42 AM, Pavel Labath <labath at google.com> wrote:

> On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> > After adding some logging I figured out that the race condition is
> caused by
> > process.Continue() did not guarantee process has been really resumed yet
> in
> > async mode, so the second wait_for_process_stop() is skipped immediately
> to
> > kill listener thread and destroying debugger. I know I have a race
> condition
> > bug here because of polling for process state, but why is lldb crashing
> when
> > listener thread has exited and SBDebugger.Destroy() is called? What is
> the
> > situation that SBDebugger.Destroy() can be called safely?
>
> My guess on the sequence of events here is this:
> - call process.Continue(), which returns immediately
> - you check process.is_stopped, which is still true
> - set self.should_quit = true
> - listener thread exits and you join in
> - you call SBDebugger.Destroy()
>
> all of this happens _before_ the process has had a chance to really
> start. So now Destroy starts destroying the process while it is just
> being started up and things go south. It could be argued that this is
> a bug in LLDB (this is the reason our TestEvents is disabled). I've
> been investigating this a bit, but it did not look easy.
>
> In any case, what you can do now is to make sure you wait for the
> eStateRunning event before you try to do anything to the process
> (including killing it). These paths are more tested and they I believe
> they should be stable.
>
> pl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160205/8fd3c0a9/attachment.html>