[Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

Thu Jan 14 03:03:17 PST 2016

I XFAIL-ed the test for Linux to get the build bot green again and filed a
bug at https://llvm.org/bugs/show_bug.cgi?id=26139

On Thu, Jan 14, 2016 at 2:18 AM Ying Chen via lldb-commits <
lldb-commits at lists.llvm.org> wrote:

> Please see attached log file.
>
> Thanks,
> Ying
>
> On Wed, Jan 13, 2016 at 5:39 PM, Enrico Granata <egranata at apple.com>
> wrote:
>
>> 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 <chying at 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
>>
>> Thanks,
>> Ying
>>
>> On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits <
>> lldb-commits at lists.llvm.org> wrote:
>>
>>>
>>> On Jan 13, 2016, at 11:26 AM, Zachary Turner <zturner at 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 <egranata at apple.com>
>>> wrote:
>>>
>>>>
>>>> On Jan 13, 2016, at 10:34 AM, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata <egranata at apple.com>
>>>> wrote:
>>>>
>>>>> On Jan 13, 2016, at 10:21 AM, Zachary Turner <zturner at google.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
>>>>> lldb-commits at 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
>>>>>> +    @expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
>>>>>> buildbot")
>>>>>> +    @expectedFlakeyLinux("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 at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160114/12107b22/attachment-0001.html>