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 <lab...@google.com> wrote: > On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev > <lldb-dev@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 >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev