[lldb-dev] Synchronous execution with process plugin

[Zachary Turner]

I'm a little confused.  You said that in synchronous execution, Launch
won't return until the process has stopped.  That makes sense, but it
already checks that the process has stopped once regardless of whether
synchronous execution is set.  Then, it calls PrivateResume() (even if
synchronous_execution is set), and then waits for the process to stop
again?  What would trigger this second stop?  Target::Launch already asked
it to resume, so now it's happily running while Target::Launch is waiting
for it to stop a second time.

On Fri, Mar 20, 2015 at 4:23 PM <jingham at apple.com> wrote:

> In synchronous execution, the "Launch" command won't return till the
> process has stopped.  The point of synchronous execution is that you can do:
>
> break set -n foo
> run
> bt
>
> So "run" can't return till the breakpoint has been hit.  That is why it
> waits for the process to stop.  I'm not quite sure why this is done in
> Target::Launch, in other cases (e.g. in for "step" and "continue" the
> command object is the one that takes care of waiting for the stop.  Launch
> is a little funny however, because it can't use the normal process wait
> mechanism to do its job since the real process isn't alive when it has to
> start waiting...
>
> I think the reason you are hanging here is that the code that reads in all
> the init statements runs an event loop temporarily while it is reading them
> in, and the kills that and hands off the the real command execution loop,
> and this continuation gets lost in the handoff.  I thought Greg had already
> fixed that, but maybe it's still sitting in his queue.
>
> Jim
>
>
>
>
> > On Mar 20, 2015, at 3:57 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I ran into an issue earlier where I tried to make a .lldbinit file with
> some lines like this:
> >
> > file a.out
> > run
> >
> >
> > When this happens the process runs, the breakpoint gets hit and I see
> the source listing, it returns to the lldb prompt, but then I can't type
> anything.  It appears LLDB is deadlocked inside of Target::Launch() at the
> following location:
> >
> >                 if (!synchronous_execution)
> >                     m_process_sp->RestoreProcessEvents ();
> >
> >                 error = m_process_sp->PrivateResume();
> >
> >                 if (error.Success())
> >                 {
> >                     // there is a race condition where this thread will
> return up the call stack to the main command
> >                     // handler and show an (lldb) prompt before
> HandlePrivateEvent (from PrivateStateThread) has
> >                     // a chance to call PushProcessIOHandler()
> >                     m_process_sp->SyncIOHandler(2000);
> >
> >                     if (synchronous_execution)
> >                     {
> >
> > state = m_process_sp->WaitForProcessToStop (NULL, NULL, true,
> hijack_listener_sp.get(), stream);
> >                         const bool must_be_alive = false; //
> eStateExited is ok, so this must be false
> >                         if (!StateIsStoppedState(state, must_be_alive))
> >                         {
> >                             error.SetErrorStringWithFormat("process
> isn't stopped: %s", StateAsCString(state));
> >                         }
> >                     }
> >                 }
> >
> > Normally when I'm using LLDB and entering the commands myself, this
> synchronous_execution value is not set, and everything works as expected.
> How is this supposed to work?  What does my plugin need to do differently
> in order to handle this case?  The process has already stopped once and
> resumed, so I'm not sure why it would need to stop again?  I see that it's
> not restoring process events in the case of synchronous execution, so maybe
> it should have never resumed in the first place?
> _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150320/77bdff37/attachment.html>