I'm not sure it is deadlocking the debugger. lldb is just waiting for a stop.
For instance ^C should interrupt it, or sending a signal externally to the
process, or triggering a breakpoint or crash, etc.
Actually, Greg must have fixed the bug I was remembering, because this works
correctly for me with TOT lldb.
What happens for you if your .lldbinit has:
file a.out
break set -n main
run
For me this stops at the breakpoint at main. We still have a little clean up
to do here, because I don't see the stop notification in this case. I see:
> lldb -S cmds.lldb
(lldb) command source -s 1 'cmds.lldb'
4 locations added to breakpoint 1
(lldb)
but if I then do "bt" I'm sitting at main:
(lldb) bt
* thread #1: tid = 0x1bf8a4, function: main , stop reason = breakpoint 1.1
* frame #0: 0x0000000100018e87 Sketch`main at SKTMain.m:17
frame #1: 0x00007fff94f445ad libdyld.dylib`start
frame #2: 0x00007fff94f445ad libdyld.dylib`start
Not sure what's up with the stutter at start either. But that's a different
rabbit to chase...
Jim
> On Mar 20, 2015, at 4:40 PM, Zachary Turner <[email protected]> wrote:
>
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
> > > [email protected]
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
