<div dir="ltr">Thanks Pavel, yeah, that's what I figured out yesterday.<div>In "<span style="font-size:12.8px">So now Destroy starts destroying the process while it is just </span><span style="font-size:12.8px">being *started up* and things go south</span>", for "<span style="font-size:12.8px">started up</span>", 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 "<span style="color:rgb(80,0,80);font-size:12.8px">wait_for_process_stop()</span>" call. Just want to confirm we are on the same page. </div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 1:42 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev<br>
<span class=""><<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> After adding some logging I figured out that the race condition is caused by<br>
> process.Continue() did not guarantee process has been really resumed yet in<br>
> async mode, so the second wait_for_process_stop() is skipped immediately to<br>
> kill listener thread and destroying debugger. I know I have a race condition<br>
> bug here because of polling for process state, but why is lldb crashing when<br>
> listener thread has exited and SBDebugger.Destroy() is called? What is the<br>
> situation that SBDebugger.Destroy() can be called safely?<br>
<br>
</span>My guess on the sequence of events here is this:<br>
- call process.Continue(), which returns immediately<br>
- you check process.is_stopped, which is still true<br>
- set self.should_quit = true<br>
- listener thread exits and you join in<br>
- you call SBDebugger.Destroy()<br>
<br>
all of this happens _before_ the process has had a chance to really<br>
start. So now Destroy starts destroying the process while it is just<br>
being started up and things go south. It could be argued that this is<br>
a bug in LLDB (this is the reason our TestEvents is disabled). I've<br>
been investigating this a bit, but it did not look easy.<br>
<br>
In any case, what you can do now is to make sure you wait for the<br>
eStateRunning event before you try to do anything to the process<br>
(including killing it). These paths are more tested and they I believe<br>
they should be stable.<br>
<span class="HOEnZb"><font color="#888888"><br>
pl<br>
</font></span></blockquote></div><br></div>