[lldb-dev] Synchronous execution with process plugin

[Zachary Turner]

If that's the case, then a .lldbinit file like this:

file a.out
run

Will deadlock the debugger, because the real stop never comes?

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

> That's the stop at entry stop.  The code you quoted is in a block that
> starts with:
>
>         if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false)
>         {
>
> So we've stopped at the entry point, but the user didn't want to know
> about that, so we resume and wait for a "real" stop.
>
> Jim
>
>
> > On Mar 20, 2015, at 4:30 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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/04c58a1e/attachment.html>