[lldb-dev] Process::SyncIOHandler(), everyone please try out the following patch

[Pavel Labath]

Re-sending the email to the list without the attachment....


On 15 April 2015 at 10:14, Pavel Labath <labath at google.com> wrote:
> Hello,
>
> I am attaching the log file. The last "step-over" command in the log
> file is the bad one, while the one before is ok. From what I can tell,
> the main difference between the two runs is that in the "bad" case,
> HandleCommand on main thread (log line 5877) returned before before
> the process started evaluating it thread plan (line 5881). In the good
> case, this order is reversed: the "Current Plan" line (5417) appears
> before the "command succeeded" line (5431). I don't know if that is
> permitted to happen, but that seems to be the main difference.
>
>
>> On 10 April 2015 at 21:04, Greg Clayton <gclayton at apple.com> wrote:
>>> Pavel,
>>>
>>> can you you look into why this is happening by adding logging to a file?
>>>
>>> What I believe should happen is:
>>>
>>> 1 - main thread: get the "n" command and issues the step and may or may not get back to printing the "(lldb) " prompt before step 2 below
>>> 2 - debugger event thread: calls Debugger::HandleProcessEvent to handle the eStateRunning event
>>> 3 - debugger event thread: might get STDOUT event for the "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" text and async prints it
>>> 4 - debugger event thread: calls Debugger::HandleProcessEvent to handle the eStateStopped event
>>> 5 - debugger event thread: has async text for stop reason "thread #1:..." and async prints it
>>>
>>>
>>> For both async prints in step 3 and 5, we call IOHandler::Hide() which for the Editline should hide the "(lldb) " prompt, show the text and call IOHandler::Referesh() to show the prompt again and any partial command you may have typed. Why that is not happening the the question. When we display the async text we run this function:
>>>
>>>      1  void
>>>      2  IOHandlerStack::PrintAsync (Stream *stream, const char *s, size_t len)
>>>      3  {
>>>      4      if (stream)
>>>      5      {
>>>      6          Mutex::Locker locker (m_mutex);
>>>      7          if (m_top)
>>>      8          {
>>>      9              Mutex::Locker locker(m_top->GetOutputMutex());
>>>     10              const bool did_hide = m_top->Hide();
>>>     11              stream->Write (s, len);
>>>     12              stream->Flush();
>>>     13              if (did_hide)
>>>     14                  m_top->Refresh();
>>>     15          }
>>>     16      }
>>>     17  }
>>>
>>> Note above on line 10 we ask the editline IOHandler to hide itself, and then we write the data on line 11 and then _only_ if we hid the IOHandler to we ask it to refresh. So the question is, is the main thread printing the "(lldb) " prompt after line 10? Does your linux process have a ProcessIOHandler, or is ProcessGDBRemote getting the stdout via async 'O' packets?
>
> We are not using 'O' packets on linux unless we are doing truly remote
> debugging. We are pushing an IOHandlerProcessSTDIO on the stack.
>
> I have placed a breakpoint on IOHandlerEditline::Hide, and I am not
> getting a hit when the wrong prompt issue appears. This seems to
> indicate that the editline handler is not at the top of the stack at
> that point. I am not sure how it could be writing prompts then, but
> that is what seems to be happening. (Note that the breakpoint is hit
> in other situations, so the editline handler is alive and kicking, but
> it's just not used this time...). Is it possible we somehow push it
> first, it writes the prompt, and then the prompt does not get hidden
> when we push process handler on top of it?
>
>
> regards,
> pl