Re-sending the email to the list without the attachment....
On 15 April 2015 at 10:14, Pavel Labath <lab...@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 <gclay...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
