Hello, so I have taken a look at this again, and I have found that at the point where we call `m_top->Hide()`, m_top is actually pointing to IOHandlerProcessSTDIO and *not* IOHandlerEditline. This obviously means that the output does not get hidden.
At the moment when I enter IOHandlerStack::PrintAsync, the main thread has already finished its work is blocked in lldb_private::Editline::GetCharacter. I'm suspecting that the process I/O handler gets pushed on top of editline during one of the internal process start-stop events that get handled as a part of the step-over handling, but I have not confirmed this yet. I will continue investigating next week, but I am writing this now in case you happen to know what the problem is or how to fix it. In any case, have a nice weekend, pl On 10 April 2015 at 21:04, Greg Clayton <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> Try this one out and let me know if anything improves? >>>> >>>> >>>> >>>> >>>>> On Apr 9, 2015, at 11:23 AM, Zachary Turner <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>>>> On 8 April 2015 at 16:35, Greg Clayton <[email protected]> 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 >>>>>>> [email protected] >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> [email protected] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>> >>> > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
