[lldb-dev] Race condition during process launch

[Pavel Labath]

Greetings fellow developers,

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.

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.

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).

This happens on linux in about 80% of cases when I run:
lldb a.out -o "br set -n main" -o "process launch"
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.

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?

regards,
pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150210/43f8e728/attachment.html>