Yeah, this stuff is little tricky. Feel free to ask about anything that seems opaque...
Jim > On Feb 11, 2015, at 1:27 AM, Pavel Labath <lab...@google.com> wrote: > > Thanks a lot for the explanation. This makes things much clearer. I'll try to > implement something along these lines. > > regards, > pavel > > On 10 February 2015 at 18:31, <jing...@apple.com> wrote: > > > On Feb 10, 2015, at 3:14 AM, Pavel Labath <lab...@google.com> wrote: > > > > 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? > > At present we really only support one listener handling process events at a > time. And for complex little two-steps like handling the initial stops in > launch, or running functions in the target, there are intermediate events > which would just confuse the agent that requested the dance. You do want to > hide all those events from the caller. > > So something like process launch, which is going to handle a few stops and > restarts for its own purposes, should hijack the process broadcaster. > > The HandleProcessEvent stuff doesn't really care which Listener is causing > events to get pulled off the broadcaster, so that isn't a worry. And then if > the hijacking listener stops at some event that is interesting to the > original Listener, then it can just forward the event on. > > For instance, RunThreadPlan - which is actually the runner for Function > calling plans (I had more ambitions for it at first, but it's become pretty > specialized...) does a pretty complex set of tricks. It handles > auto-continuing from breakpoints if requested, and will interrupt execution > to switch from single thread execution to running all threads. None of this > would make any sense to somebody who said "run this expression for me." So > we install an Hijacking listener and then handle all the stages of running > the function using that. If the function call succeeds, then we eat all the > events and return the result. But for instance if you hit a breakpoint (and > the caller wants to stop at breakpoint hits in function calls) then on the > way out, we forward the breakpoint stop event to the original listener so > that the stop can be handled by the normal Process Listener just like any > other stop. > > Jim > > > > > > regards, > > pavel > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
