[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

Wed Jan 13 18:18:35 PST 2016

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160113/7353e4c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestCommandScriptImmediateOutput_fail.log
Type: text/x-log
Size: 11167 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160113/7353e4c2/attachment-0001.bin>