From the buildbot log it’s quite hard to tell what could be going on Is there any chance you guys could run the test by hand with the “-t -v” flags to the dotest.py driver and attach the output of the run?
That might help figure out where the issue lies > On Jan 13, 2016, at 5:35 PM, Ying Chen <chy...@google.com> wrote: > > Hello Enrico, > > The new test has been failing on Ubuntu buildbot. But it's passing on some > offline Ubuntu machines, I don't understand what caused the difference. > Could you please help to take a look? > > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299 > <http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299> > > Thanks, > Ying > > On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits > <lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>> wrote: > >> On Jan 13, 2016, at 11:26 AM, Zachary Turner <ztur...@google.com >> <mailto:ztur...@google.com>> wrote: >> >> Thanks! btw would having the command write its output to a file instead of >> stdout solve the pexpect problme as well? >> > > That’s possible - but I would need to play with it a little bit to convince > myself that it really is a faithful reproduction of my original issue > It’ll take me a little while to get to it - stay tuned. > >> On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata <egran...@apple.com >> <mailto:egran...@apple.com>> wrote: >> >>> On Jan 13, 2016, at 10:34 AM, Zachary Turner <ztur...@google.com >>> <mailto:ztur...@google.com>> wrote: >>> >>> >>> >>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata <egran...@apple.com >>> <mailto:egran...@apple.com>> wrote: >>>> On Jan 13, 2016, at 10:21 AM, Zachary Turner <ztur...@google.com >>>> <mailto:ztur...@google.com>> wrote: >>>> >>>> >>>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits >>>> <lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>> wrote: >>>> + >>>> +class CommandScriptImmediateOutputTestCase (PExpectTest): >>>> Does the bug that you were trying to fix occur only when using the >>>> command_script.py file from the lldb command line? If you load it from >>>> within lldb via an LLDB command, does the problem still occur? If the >>>> problem you are fixing is not specific to the LLDB command line, I would >>>> prefer if you write this not as a pexpect test. >>> >>> I would love to not touch pexpect :-) But in this case, I can’t see a way >>> around it. I am trying to detect whether some text is “physically” printed >>> to stdout. And pexpect seems the most obvious straightforward way to get >>> that to happen. Note that, in this bug, the result object is filled in >>> correctly even if nothing gets printed, so looking at the result won’t >>> quite cut it - it really needs to detect output to stdout. >>> You're calling result.SetImmediateOutputFile(sys.__stdout__). Wouldn't it >>> work to use a file on the file system here, and then you open that file and >>> look at it after running the commands? It wouldn't work in remote cases, >>> but it already doesn't work on remote cases anyway (as you point out below) >>> >>> >>>> >>>> + >>>> + mydir = TestBase.compute_mydir(__file__) >>>> + >>>> + def setUp(self): >>>> + # Call super's setUp(). >>>> + PExpectTest.setUp(self) >>>> + >>>> + @skipIfRemote # test not remote-ready llvm.org/pr24813 >>>> <http://llvm.org/pr24813> >>>> + @expectedFlakeyFreeBSD("llvm.org/pr25172 <http://llvm.org/pr25172> >>>> fails rarely on the buildbot") >>>> + @expectedFlakeyLinux("llvm.org/pr25172 <http://llvm.org/pr25172>") >>>> Are these necessary? The windows one is necessary (but not if you change >>>> this to not being a pexpect test as I've requested above), but why are the >>>> other ones necessary? >>> >>> >>> Do we support remote pexpect? As for FreeBSD and Linux, they might not be >>> necessary, but I’d rather much remove them (or let the relevant platform >>> owners) remove them in a separate commit >>> >>> No remote pexpect, so the @skipIfRemote probably needs to be there. But I >>> think everyone should be checking in tests enabled by default in the widest >>> set of environments possible that you aren't completely sure are broken. >>> It should be up to the platform holders to disable broken tests, not to >>> enable working tests. Because it's much easier to notice a broken test >>> going in than it is to notice a working test went in disabled (because >>> who's going to think to test it out?). >> >> >> This is a fair point. I’ll enable those platforms in a subsequent commit ASAP >> >> >> Thanks, >> - Enrico >> 📩 egranata@.com ☎️ 27683 >> > > > > Thanks, > - Enrico > 📩 egranata@.com ☎️ 27683 > > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits> > > Thanks, - Enrico 📩 egranata@.com ☎️ 27683
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
