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
On Mon, Apr 6, 2015 at 4:44 PM Greg Clayton <gclay...@apple.com> wrote:
> 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.
>
> Do you still see overlapping (lldb) prompts even with no fixes? Or do
> things work correctly for you with top of tree?
>
> Greg
>
>
> > On Apr 6, 2015, at 3:59 PM, Zachary Turner <ztur...@google.com> wrote:
> >
> > 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)
> >
> > On Mon, Apr 6, 2015 at 3:48 PM Greg Clayton <gclay...@apple.com> wrote:
> >
> >
> > Try this one.
> >
> > > On Apr 6, 2015, at 3:34 PM, Zachary Turner <ztur...@google.com> wrote:
> > >
> > > 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:
> > >
> > > d:\src\llvmbuild\ninja\bin>lldb
> > > (lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'
> > > (lldb) file d:\testexe\simple_step.exe
> > > Current executable set to 'd:\testexe\simple_step.exe' (i686).
> > > (lldb) break set -f simple_step.cpp -l 11
> > > Breakpoint 1: where = simple_step.exe`main + 54 at simple_step.cpp:11,
> address = 0x00416096
> > > (lldb) run
> > > Process 11400 launching
> > > (lldb) Process 11400 launched: 'd:\testexe\simple_step.exe' (i686)
> > > (lldb) Process 11400 stopped
> > > * thread #1: tid = 0x376c, 0x00cd6096 simple_step.exe`main(argc=1,
> argv=0x01149028) + 54 at simple_step.cpp:11, stop reason = breakpoint 1.1
> > > frame #0: 0x00cd6096 simple_step.exe`main(argc=1, argv=0x01149028)
> + 54 at simple_step.cpp:11
> > > 8
> > > 9 int main(int argc, char **argv) {
> > > 10 int fib7 = fib(7);
> > > -> 11 printf("The value of fib(7) is %u\n", fib7);
> > > 12 return 0;
> > > 13 }
> > > (lldb)
> > >
> > > If I make a .lldbinit file with the exact same set of commands and
> start lldb, I get this output.
> > >
> > > d:\src\llvmbuild\ninja\bin>lldb
> > > (lldb) command source -s 1 'd:\src\llvmbuild\ninja\bin\.\.lldbinit'
> > > Process 5288 launching
> > > (lldb) (lldb)
> > >
> > > 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.
> > >
> > > On Mon, Apr 6, 2015 at 3:28 PM Zachary Turner <ztur...@google.com>
> wrote:
> > > Hi Greg,
> > >
> > > This latest patch appears to have ANSI escape codes in it. Any chance
> you can re-upload?
> > >
> > > On Mon, Apr 6, 2015 at 2:41 PM Greg Clayton <gclay...@apple.com>
> wrote:
> > > 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?
> > >
> > > Try this patch:
> > >
> > >
> > >
> > > 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(iohandler_id, <timeout>).
> > >
> > > Let me know if this makes anything better or worse?
> > >
> > > > On Apr 6, 2015, at 2:03 PM, Ed Maste <ema...@freebsd.org> wrote:
> > > >
> > > > On 6 April 2015 at 16:37, Greg Clayton <gclay...@apple.com> wrote:
> > > >> Can everyone try and apply the following patch and run your test
> suite and also use LLDB for a while?
> > > >
> > > > Test run looks equivalent on FreeBSD - I had two failures on my
> desktop:
> > > >
> > > > FAIL: LLDB (suite) :: TestEvents.py (FreeBSD feynman 10.1-STABLE
> > > > FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26
> > > > 16:07:47 EDT 2015
> > > > emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-
> stable-10/sys/GENERIC
> > > > amd64 amd64)
> > > > FAIL: LLDB (suite) :: TestSendSignal.py (FreeBSD feynman 10.1-STABLE
> > > > FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26
> > > > 16:07:47 EDT 2015
> > > > emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-
> stable-10/sys/GENERIC
> > > > amd64 amd64)
> > > >
> > > > The first fails intermittently for me under load, while the second
> has
> > > > been failing for a while.
> > > >
> > > > The change seems to make the lldb-prompt-at-the-wrong-time problem
> > > > worse (or at least, no better) during interactive single stepping
> > > > though. For example:
> > > >
> > > > % bin/lldb /bin/ls
> > > > (lldb) target create "/bin/ls"
> > > > Current executable set to '/bin/ls' (x86_64).
> > > > (lldb) b main
> > > > Breakpoint 1: where = ls`main + 33 at ls.c:163, address =
> 0x00000000004023f1
> > > > (lldb) run
> > > > Process 58244 launching
> > > > Process 58244 launched: '/bin/ls' (x86_64)
> > > > (lldb) Process 58244 stopped
> > > > * thread #1: tid = 103132, 0x00000000004023f1 ls`main(argc=1,
> > > > argv=0x00007fffffffe598) + 33 at ls.c:163, stop reason = breakpoint
> > > > 1.1
> > > > frame #0: 0x00000000004023f1 ls`main(argc=1,
> > > > argv=0x00007fffffffe598) + 33 at ls.c:163
> > > > 160 #ifdef COLORLS
> > > > 161 char termcapbuf[1024]; /* termcap definition buffer
> */
> > > > 162 char tcapbuf[512]; /* capability buffer */
> > > > -> 163 char *bp = tcapbuf;
> > > > 164 #endif
> > > > 165
> > > > 166 (void)setlocale(LC_ALL, "");
> > > > step
> > > > Process 58244 stopped
> > > > * thread #1: tid = 103132, 0x00000000004023fa ls`main(argc=1,
> > > > argv=0x00007fffffffe598) + 42 at ls.c:166, stop reason = step in
> > > > frame #0: 0x00000000004023fa ls`main(argc=1,
> > > > argv=0x00007fffffffe598) + 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)) {
> > > > (lldb) step
> > > > Process 58244 stopped
> > > > * thread #1: tid = 103132, 0x0000000800dab011
> > > > libc.so.7`setlocale(category=0, locale=0x0000000000406373) + 33 at
> > > > setlocale.c:113, stop reason = step in
> > > > frame #0: 0x0000000800dab011 libc.so.7`setlocale(category=0,
> > > > locale=0x0000000000406373) + 33 at setlocale.c:113
> > > > 110 return (NULL);
> > > > 111 }
> > > > 112
> > > > -> 113 if (locale == NULL)
> > > > 114 return (category != LC_ALL ?
> > > > 115 current_categories[category] :
> currentlocale());
> > > > 116
> > > > (lldb) step
> > > > (lldb) Process 58244 stopped
> > > > * thread #1: tid = 103132, 0x0000000800dab01a
> > > > libc.so.7`setlocale(category=0, locale=0x0000000000406373) + 42 at
> > > > setlocale.c:121, stop reason = step in
> > > > frame #0: 0x0000000800dab01a libc.so.7`setlocale(category=0,
> > > > locale=0x0000000000406373) + 42 at setlocale.c:121
> > > > 118 * Default to the current locale for everything.
> > > > 119 */
> > > > 120 for (i = 1; i < _LC_LAST; ++i)
> > > > -> 121 (void)strcpy(new_categories[i],
> current_categories[i]);
> > > > 122
> > > > 123 /*
> > > > 124 * Now go fill up new_categories from the locale
> argument
> > >
> > > _______________________________________________
> > > 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
