[lldb-dev] Process::SyncIOHandler(), everyone please try out the following patch

Greg Clayton gclayton at apple.com
Mon Apr 6 16:44:37 PDT 2015


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 <zturner at 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 <gclayton at apple.com> wrote:
> 
> 
> Try this one.
> 
> > On Apr 6, 2015, at 3:34 PM, Zachary Turner <zturner at 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 <zturner at 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 <gclayton at 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 <emaste at freebsd.org> wrote:
> > >
> > > On 6 April 2015 at 16:37, Greg Clayton <gclayton at 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 at 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 at 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 at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 





More information about the lldb-dev mailing list