<div dir="ltr">By the way, the original one-liner patch doesn't seem to fix the double prompt for me, and it also doesn't fix the case of printing a stack trace after stopping at a breakpoint through a .lldbinit file.  In other words, this is an interactive session:<br><div><br></div><div><div>d:\src\llvmbuild\ninja\bin>lldb</div><div>(lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'</div><div>(lldb) file d:\testexe\simple_step.exe</div><div>Current executable set to 'd:\testexe\simple_step.exe' (i686).</div><div>(lldb) break set -f simple_step.cpp -l 11</div><div>Breakpoint 1: where = simple_step.exe`main + 54 at simple_step.cpp:11, address = 0x00416096</div><div>(lldb) run</div><div>Process 11400 launching</div><div>(lldb) Process 11400 launched: 'd:\testexe\simple_step.exe' (i686)</div><div>(lldb) Process 11400 stopped</div><div>* thread #1: tid = 0x376c, 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028) + 54 at simple_step.cpp:11, stop reason = breakpoint 1.1</div><div>    frame #0: 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028) + 54 at simple_step.cpp:11</div><div>   8</div><div>   9    int main(int argc, char **argv) {</div><div>   10       int fib7 = fib(7);</div><div>-> 11       printf("The value of fib(7) is %u\n", fib7);</div><div>   12       return 0;</div><div>   13   }</div><div>(lldb)</div></div><div><br></div><div>If I make a .lldbinit file with the exact same set of commands and start lldb, I get this output.</div><div><br></div><div><div>d:\src\llvmbuild\ninja\bin>lldb</div><div>(lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'</div><div>Process 5288 launching</div><div>(lldb) (lldb)</div></div><div><br></div><div>The one-liner patch doesn't change anything for me, so it seems it doesn't fix everything?  I haven't tried the second patch though because of the ANSI escape codes.</div></div><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 3:28 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Greg,<br><br><div>This latest patch appears to have ANSI escape codes in it.  Any chance you can re-upload?</div></div><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 2:41 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So do you still have problems with the prompt coming out at the wrong time or getting interspersed on FreeBSD with top of tree? It is just made worse by this patch?<br>
<br>
Try this patch:<br>
<br>
<br>
<br>
It changes the Predicate to use a uint32_t instead and it increments the predicate when the process resumes. Clients must first get the current IOHandler ID, then call something that resumes the process (continue or step) and then call Process::SyncIOHandler(<u></u>iohandl<u></u>er_id, <timeout>).<br>
<br>
Let me know if this makes anything better or worse?<br>
<br>
> On Apr 6, 2015, at 2:03 PM, Ed Maste <<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>> wrote:<br>
><br>
> On 6 April 2015 at 16:37, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
>> Can everyone try and apply the following patch and run your test suite and also use LLDB for a while?<br>
><br>
> Test run looks equivalent on FreeBSD - I had two failures on my desktop:<br>
><br>
> FAIL: LLDB (suite) :: TestEvents.py (FreeBSD feynman 10.1-STABLE<br>
> FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26<br>
> 16:07:47 EDT 2015<br>
> emaste@feynman:/tank/emaste/<u></u>ob<u></u>j/tank/emaste/src/git-<u></u>stable-<u></u>10/sys/GENERIC<br>
> amd64 amd64)<br>
> FAIL: LLDB (suite) :: TestSendSignal.py (FreeBSD feynman 10.1-STABLE<br>
> FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26<br>
> 16:07:47 EDT 2015<br>
> emaste@feynman:/tank/emaste/<u></u>ob<u></u>j/tank/emaste/src/git-<u></u>stable-<u></u>10/sys/GENERIC<br>
> amd64 amd64)<br>
><br>
> The first fails intermittently for me under load, while the second has<br>
> been failing for a while.<br>
><br>
> The change seems to make the lldb-prompt-at-the-wrong-time problem<br>
> worse (or at least, no better) during interactive single stepping<br>
> though. For example:<br>
><br>
> % bin/lldb /bin/ls<br>
> (lldb) target create "/bin/ls"<br>
> Current executable set to '/bin/ls' (x86_64).<br>
> (lldb) b main<br>
> Breakpoint 1: where = ls`main + 33 at ls.c:163, address = 0x00000000004023f1<br>
> (lldb) run<br>
> Process 58244 launching<br>
> Process 58244 launched: '/bin/ls' (x86_64)<br>
> (lldb) Process 58244 stopped<br>
> * thread #1: tid = 103132, 0x00000000004023f1 ls`main(argc=1,<br>
> argv=0x00007fffffffe598) + 33 at ls.c:163, stop reason = breakpoint<br>
> 1.1<br>
>    frame #0: 0x00000000004023f1 ls`main(argc=1,<br>
> argv=0x00007fffffffe598) + 33 at ls.c:163<br>
>   160  #ifdef COLORLS<br>
>   161          char termcapbuf[1024];  /* termcap definition buffer */<br>
>   162          char tcapbuf[512];      /* capability buffer */<br>
> -> 163          char *bp = tcapbuf;<br>
>   164  #endif<br>
>   165<br>
>   166          (void)setlocale(LC_ALL, "");<br>
> step<br>
> Process 58244 stopped<br>
> * thread #1: tid = 103132, 0x00000000004023fa ls`main(argc=1,<br>
> argv=0x00007fffffffe598) + 42 at ls.c:166, stop reason = step in<br>
>    frame #0: 0x00000000004023fa ls`main(argc=1,<br>
> argv=0x00007fffffffe598) + 42 at ls.c:166<br>
>   163          char *bp = tcapbuf;<br>
>   164  #endif<br>
>   165<br>
> -> 166          (void)setlocale(LC_ALL, "");<br>
>   167<br>
>   168          /* Terminal defaults to -Cq, non-terminal defaults to -1. */<br>
>   169          if (isatty(STDOUT_FILENO)) {<br>
> (lldb) step<br>
> Process 58244 stopped<br>
> * thread #1: tid = 103132, 0x0000000800dab011<br>
> libc.so.7`setlocale(category=<u></u>0<u></u>, locale=0x0000000000406373) + 33 at<br>
> setlocale.c:113, stop reason = step in<br>
>    frame #0: 0x0000000800dab011 libc.so.7`setlocale(category=<u></u>0<u></u>,<br>
> locale=0x0000000000406373) + 33 at setlocale.c:113<br>
>   110                  return (NULL);<br>
>   111          }<br>
>   112<br>
> -> 113          if (locale == NULL)<br>
>   114                  return (category != LC_ALL ?<br>
>   115                      current_categories[category] : currentlocale());<br>
>   116<br>
> (lldb) step<br>
> (lldb) Process 58244 stopped<br>
> * thread #1: tid = 103132, 0x0000000800dab01a<br>
> libc.so.7`setlocale(category=<u></u>0<u></u>, locale=0x0000000000406373) + 42 at<br>
> setlocale.c:121, stop reason = step in<br>
>    frame #0: 0x0000000800dab01a libc.so.7`setlocale(category=<u></u>0<u></u>,<br>
> locale=0x0000000000406373) + 42 at setlocale.c:121<br>
>   118           * Default to the current locale for everything.<br>
>   119           */<br>
>   120          for (i = 1; i < _LC_LAST; ++i)<br>
> -> 121                  (void)strcpy(new_categories[i]<u></u><u></u>, current_categories[i]);<br>
>   122<br>
>   123          /*<br>
>   124           * Now go fill up new_categories from the locale argument<br>
<br>
______________________________<u></u><u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-dev</a><br>
</blockquote></div></blockquote></div>