Behavior is identical with and without the patch - double prompt, no source listing. It's possible the patch changes the nature of the race in such a way that i might see different results after many runs, but I couldn't see anything after ~10 runs<br><div class="gmail_quote">On Mon, Apr 6, 2015 at 4:44 PM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We need to come up with a bullet proof way of making this just work. Right now we have the sync hack and that is obviously working for reasons no one understands because it introduces 2 second delays which masks the true issue that needs to be fixed.<br>
<br>
Do you still see overlapping (lldb) prompts even with no fixes? Or do things work correctly for you with top of tree?<br>
<br>
Greg<br>
<br>
<br>
> On Apr 6, 2015, at 3:59 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Same thing. Double prompt and no source listing when the breakpoint is hit. If there's any way that I can help diagnose let me know (logs, etc)<br>
><br>
> On Mon, Apr 6, 2015 at 3:48 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
><br>
><br>
> Try this one.<br>
><br>
> > On Apr 6, 2015, at 3:34 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > 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>
> ><br>
> > d:\src\llvmbuild\ninja\bin><u></u>lldb<br>
> > (lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\<u></u>.lldbinit'<br>
> > (lldb) file d:\testexe\simple_step.exe<br>
> > Current executable set to 'd:\testexe\simple_step.exe' (i686).<br>
> > (lldb) break set -f simple_step.cpp -l 11<br>
> > Breakpoint 1: where = simple_step.exe`main + 54 at simple_step.cpp:11, address = 0x00416096<br>
> > (lldb) run<br>
> > Process 11400 launching<br>
> > (lldb) Process 11400 launched: 'd:\testexe\simple_step.exe' (i686)<br>
> > (lldb) Process 11400 stopped<br>
> > * thread #1: tid = 0x376c, 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028) + 54 at simple_step.cpp:11, stop reason = breakpoint 1.1<br>
> > frame #0: 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028) + 54 at simple_step.cpp:11<br>
> > 8<br>
> > 9 int main(int argc, char **argv) {<br>
> > 10 int fib7 = fib(7);<br>
> > -> 11 printf("The value of fib(7) is %u\n", fib7);<br>
> > 12 return 0;<br>
> > 13 }<br>
> > (lldb)<br>
> ><br>
> > If I make a .lldbinit file with the exact same set of commands and start lldb, I get this output.<br>
> ><br>
> > d:\src\llvmbuild\ninja\bin><u></u>lldb<br>
> > (lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\<u></u>.lldbinit'<br>
> > Process 5288 launching<br>
> > (lldb) (lldb)<br>
> ><br>
> > 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.<br>
> ><br>
> > On Mon, Apr 6, 2015 at 3:28 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> > Hi Greg,<br>
> ><br>
> > This latest patch appears to have ANSI escape codes in it. Any chance you can re-upload?<br>
> ><br>
> > 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>
> > 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>iohandler_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>obj/tank/emaste/src/git-<u></u>stable-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>obj/tank/emaste/src/git-<u></u>stable-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, locale=0x0000000000406373) + 33 at<br>
> > > setlocale.c:113, stop reason = step in<br>
> > > frame #0: 0x0000000800dab011 libc.so.7`setlocale(category=<u></u>0,<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, locale=0x0000000000406373) + 42 at<br>
> > > setlocale.c:121, stop reason = step in<br>
> > > frame #0: 0x0000000800dab01a libc.so.7`setlocale(category=<u></u>0,<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>, current_categories[i]);<br>
> > > 122<br>
> > > 123 /*<br>
> > > 124 * Now go fill up new_categories from the locale argument<br>
> ><br>
> > ______________________________<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>mailman/listinfo/lldb-dev</a><br>
><br>
<br>
</blockquote></div>