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 <jing...@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 <ztur...@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 <jing...@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 <ztur...@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@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
