[Lldb-commits] [lldb] r202525 - Fixed all overlapping prompt issues.

[Greg Clayton]

So the timing of when the process IO handler gets pushed seems to be the timing difference. On MacOSX, the IOHandlerProcessSTDIO gets pushed as we are handling the "process launch" or "process attach" and before it asks for another line, the IOHandlerProcessSTDIO is already pushed. Not so for the linux and free bsd case. Does that sound like what you are seeing?

On Mar 4, 2014, at 1:18 PM, Ed Maste <emaste at freebsd.org> wrote:

> Hi Greg,
> 
> On 3 March 2014 16:09, Greg Clayton <gclayton at apple.com> wrote:
>> 4 - continue
>>        IOHandlerProcessSTDIO gets pushed
>>        we get eStateRunning event and any message gets placed into stream
>>        stream gets printed to debugger console
>> 
>>        [0] - IOHanderEditline
>>        [1] - IOHandlerProcessSTDIO
>> 
>> 5 - hit breakpoint or finish step
>>        stdout gets placed into stream (if any)
>>        stderr gets placed into stream (if any)
>>        get eStateStopped event and stop info gets placed into stream (like thread and stack frame zero)
>>        stream gets printed to debugger console
>>        IOHandlerProcessSTDIO gets popped which causes the "(lldb) " prompt to show up
>> 
>>        [0] - IOHanderEditline
> 
> From what I can see this is what happens, but the (lldb) prompt comes
> out after IOHandlerProcessSTDIO is pushed.
> 
> I added some logging where IOHandlers are pushed/popped, and in
> PrivateGetLine().  I'm not completely sure how the logging will
> interact with the debugger and target I/O; with that said, this is
> what I see.  This is with log enable -p, showing the pid/tid that
> produced the log message.
> 
> step
> [15e8/18db5]: process 5611 resuming (continue)
> [15e8/18db5]: ProcessMonitor::Resume() resuming pid 5611 with signal (null)
> [15e8/18db5]: ProcessMonitor::Resume() resuming result = true
> [15e8/1898c]: ::PushIOHandler push iohandler 0x808cc2300
> [15e8/18913]: ProcessMonitor::MonitorSIGTRAP() received breakpoint
> event, tid = 103336
> [15e8/18db5]: ::PrivateGetLine
> [15e8/1898c]: ::PushIOHandler deactivated 0x808d34340
> (lldb) [15e8/1898c]: ProcessPOSIX::RefreshStateAfterStop(),
> message_queue size = 1, pid = 103336
> [15e8/1898c]: ProcessFreeBSD::UpdateThreadList (pid = 5611)
> [15e8/1898c]: ProcessFreeBSD::UpdateThreadList existing tid = 103336
> [15e8/1898c]: process 5611 resuming (step)
> [15e8/18913]: ProcessMonitor::MonitorSIGTRAP() received trace event,
> tid = 103336  : si_code = 2
> [15e8/1898c]: ProcessPOSIX::RefreshStateAfterStop(), message_queue
> size = 1, pid = 103336
> [15e8/1898c]: ProcessFreeBSD::UpdateThreadList (pid = 5611)
> [15e8/1898c]: ProcessFreeBSD::UpdateThreadList existing tid = 103336
> Process 5611 stopped
> * thread #1: tid = 103336, 0x0000000000403072 ls`main(argc=1,
> argv=0x00007fffffffd578) + 18 at ls.c:166, stop reason = step in
>    frame #0: 0x0000000000403072 ls`main(argc=1,
> argv=0x00007fffffffd578) + 18 at ls.c:166
>   163          char *bp = tcapbuf;
>   164  #endif
>   165
> -> 166          (void)setlocale(LC_ALL, "");
>   167
>   168          /* Terminal defaults to -Cq, non-terminal defaults to -1. */
>   169          if (isatty(STDOUT_FILENO)) {
> [15e8/188d6]: ::PopIOHandler top iohandler = 0x808cc2300
> [15e8/188d6]: ::PopIOHandler popped, new top = 0x808d34340
> 
> So it looks like PrivateGetLine is executing simultaneously with the
> IOHandler manipulation, and manages to output its prompt before it's
> actually deactivated.  (Interestingly this looks like it happens at
> the same time as the inferior process trace trap callback is
> executing, too.)