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

[Pavel Labath]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lldb-prompt.log
Type: text/x-log
Size: 918593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150415/72eb3e71/attachment.bin>