<div dir="ltr">Greetings fellow developers,<div><br></div><div>I have been debugging an issue, where starting an inferior process from lldb command line results in lldb lockup. I have traced the problem to a race condition in waiting for process events.</div><div><br></div><div>Normally, we have the event handler thread waiting for (all) events in Debugger::DefaultEventHandler. Additionally, when we start a process with -o "process launch", we end up calling (in the main thread) Target::Launch with synchronous_execution=true. This results in a call to Process::WaitForProcessToStop(), which tries to wait for the process state change messages on the same listener as the first thread.</div><div><br></div><div>This results in a race between the two threads. If all the events are processed by the event-handler thread, the main thread will not receive the Stop event and will end up waiting forever, locking up the debugger. When the main thread manages to catch the Stop event everything proceeds normally (as far as I can tell).</div><div><br></div><div>This happens on linux in about 80% of cases when I run:</div><div>lldb a.out -o "br set -n main" -o "process launch"</div><div>It happens both with local debugging and llgs. I haven't managed to reproduce it on mac, but I suspect this is simply due to different thread scheduling, as the code in question is platform independent.</div><div><br></div><div>I was wondering if someone could advise on the correct solution to this problem. Obviously, we need the main thread to always receive the stop event. However, I am unsure what is the correct solution. Can I just hijack all the event from the event-handler thread? Will something bad happen if those events will not be processed there? Or should there be another listener listening for the stop events here?</div><div><br></div><div>regards,</div><div>pavel</div></div>