Hello,
I am at a conference today and tomorrow. I will take a look at this on
wednesday and let you know.
cheers,
pl
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?
>
> Greg
>
>> On Apr 10, 2015, at 3:12 AM, Pavel Labath <lab...@google.com> wrote:
>>
>> Sadly, still not working on Linux :(
>>
>> Process 24525 stopped
>> * thread #1: tid = 24525, 0x000000000040075e a.out`main + 558 at
>> a.cc:33, name = 'a.out', stop reason = step over
>> frame #0: 0x000000000040075e a.out`main + 558 at a.cc:33
>> 30 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 31 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 32 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> -> 33 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 34 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 35 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 36 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> (lldb) n
>> (lldb) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Process 24525 stopped
>> * thread #1: tid = 24525, 0x0000000000400772 a.out`main + 578 at
>> a.cc:34, name = 'a.out', stop reason = step over
>> frame #0: 0x0000000000400772 a.out`main + 578 at a.cc:34
>> 31 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 32 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 33 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> -> 34 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 35 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 36 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> 37 printf("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n");
>> .....
>>
>>
>> --
>> pl
>>
>>
>> On 10 April 2015 at 01:06, Greg Clayton <gclay...@apple.com> wrote:
>>> Note that my "io2.patch" removed the fix that was introduced with 234517.
>>> So it works without that fix which is good news.
>>>
>>> When sourcing files we turn off output for many things. Try your commands
>>> as:
>>>
>>> % ~/Documents/src/lldb/tot/build/Debug/lldb -o 'file
>>> d:\testexe\simple_step.exe' -o 'break set -f simple_step.cpp -l 12' -o run
>>> -o bt
>>>
>>> The attached patch always uses the debugger output and error instead of the
>>> output and error from the current IOHandler. This shouldn't make a change,
>>> but it is the change I would want to submit.
>>>
>>>
>>>
>>>
>>> Please test this as much as you can and let me know if this fixes all your
>>> prompt issues (besides stuff not showing up when run in non-interactive
>>> mode by sourcing a commands file).
>>>
>>> Greg
>>>
>>>> On Apr 9, 2015, at 4:44 PM, Zachary Turner <ztur...@google.com> wrote:
>>>>
>>>> So my double prompt seems to be fixed, but then I reverted your change and
>>>> noticed it was still fixed. So I looked through the history a little bit,
>>>> and it appears to have been fixed by r234517. I still don't see the
>>>> output of "bt" printed when it's run from my inside my .lldbinit file.
>>>> But since r234517 fixed my double prompt, I must be having the same
>>>> problem described in the commit message, which is that I don't have an
>>>> IOHandler on my process. So maybe addressing that will fix my backtrace
>>>> as well.
>>>>
>>>> Either way, if anyone else tries this patch and also notices that the
>>>> problem is fixed, please also check whether it is fixed by 234517 without
>>>> this patch so that we are sure what exactly is causing people's problems
>>>> to go away.
>>>>
>>>> On Thu, Apr 9, 2015 at 4:05 PM Greg Clayton <gclay...@apple.com> wrote:
>>>> Try this one out and let me know if anything improves?
>>>>
>>>>
>>>>
>>>>
>>>>> On Apr 9, 2015, at 11:23 AM, Zachary Turner <ztur...@google.com> wrote:
>>>>>
>>>>> If you need a VM or something let me know I can proabbly make something
>>>>> that you can remote into and is already properly set up and ready to
>>>>> build.
>>>>>
>>>>> On Thu, Apr 9, 2015 at 11:02 AM Greg Clayton <gclay...@apple.com> wrote:
>>>>> Thanks everyone for trying this out. I will modify this patch and try
>>>>> again soon.
>>>>>
>>>>>> On Apr 9, 2015, at 7:56 AM, Pavel Labath <lab...@google.com> wrote:
>>>>>>
>>>>>> The situation is even worse on Linux, i'm afraid. Whereas I was
>>>>>> getting no wrong prompts before (at least when debugging locally), now
>>>>>> the prompt appears in the wrong place in about 10% of the cases.
>>>>>>
>>>>>> pl
>>>>>>
>>>>>> On 9 April 2015 at 15:19, Ed Maste <ema...@freebsd.org> wrote:
>>>>>>> On 8 April 2015 at 16:35, Greg Clayton <gclay...@apple.com> wrote:
>>>>>>>>
>>>>>>>> This one removes the m_iohandler_sync completely and coordinates async
>>>>>>>> IO with the IOHandlers. Let me know if this works any better for
>>>>>>>> freebsd, linux or windows.
>>>>>>>
>>>>>>> Problem persists with this version on FreeBSD, unfortunately:
>>>>>>>
>>>>>>> ...
>>>>>>> 165
>>>>>>> 166 (void)setlocale(LC_ALL, "");
>>>>>>> (lldb) step
>>>>>>> (lldb) Process 77191 stopped
>>>>>>> * thread #1: tid = 100853, 0x00000000004023fa ls`main(argc=1,
>>>>>>> argv=0x00007fffffffe588) + 42 at ls.c:166, stop reason = step in
>>>>>>> frame #0: 0x00000000004023fa ls`main(argc=1,
>>>>>>> argv=0x00007fffffffe588) + 42 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)) {
>>>>>>> step
>>>>>>> ...
>>>>>>> _______________________________________________
>>>>>>> lldb-dev mailing list
>>>>>>> lldb-dev@cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev@cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>
>>>
>>>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
