[Patch][LNT] fix python error in compile.py when runN failed

Chris Matthews chris4000 at gmail.com
Wed Jun 25 08:30:03 PDT 2014


I think the message failed to parse output is misleading.  

The problem that I have experienced several times is that no output is printed, so all I get is a "compile.py:71: error: failed to parse output: “ and nothing else, which then makes it look like LNT had a problem, not the subprocess.

For instance, this is a snippet from a recent log:

compile.py:71: error: failed to parse output: 
compile.py:74: error: stderr isn't empty: runN: ERROR: child returned error: 65.
compile.py:78: error: res != 0: 1


Not super helpful.

> On Jun 25, 2014, at 7:52 AM, Steven Wu <stevenwu at apple.com> wrote:
> 
> I agree that the original code works but it is doing more work than necessary and throw ugly python errors. This is a performance & cosmetic fix.
> 
> Steven
> 
>> On Jun 24, 2014, at 10:27 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>> 
>> It isn't clear to me this is the right patch. Where are you seeing "python errors" being dumped during "runtest compile"?
>> 
>> If I inject an error into one of the source files, what I see is this:
>> --
>> $ lnt runtest compile --sandbox $(timestamp) --cc $(which clang) --test-externals ~/test-suite-externals --test-subdir lnt-compile-suite-src/intel --test-filter=compile/403.gcc/combine.c/irgen --flags-to-test="-O0"
>> compile.py:779: note: inferred C++ compiler under test as: '/usr/bin/clang++'
>> 2014-06-24 17:25:04: creating sandbox: '2014-06-24_10-25'
>> compile.py:893: note: inferred run order to be: '600.0.34'
>> 2014-06-24 10:25:04: INFO: Loading config file: /Users/ddunbar/test-suite-externals/lnt-compile-suite-src/intel/project_list.json
>> 2014-06-24 10:25:04: INFO: run started
>> 2014-06-24 10:25:04: INFO: using CC: '/usr/bin/clang'
>> 2014-06-24 10:25:04: INFO: using CXX: '/usr/bin/clang++'
>> compile.py:71: error: failed to parse output: 
>> 
>> compile.py:74: error: stderr isn't empty: /Users/ddunbar/test-suite-externals/lnt-compile-suite-src/intel/single-file/403.gcc/combine.c:12776:1: error: unknown type name 'xxxx'
>> xxxx
>> ^
>> /Users/ddunbar/test-suite-externals/lnt-compile-suite-src/intel/single-file/403.gcc/combine.c:12777:5: error: expected ';' after top level declarator
>> xxxx
>>     ^
>>     ;
>> 2 errors generated.
>> runN: ERROR: child returned error: 1.
>> 
>> 
>> compile.py:78: error: res != 0: 1
>> --
>> which isn't pretty, but it works.
>> 
>>  - Daniel
>> 
>> 
>> 
>> On Tue, Jun 24, 2014 at 9:34 AM, Steven Wu <stevenwu at apple.com> wrote:
>> Sorry I forgot to attach the patch in the previous email. Now attached.
>> 
>> 
>> > On Jun 23, 2014, at 6:06 PM, Steven Wu <stevenwu at apple.com> wrote:
>> >
>> > LNT currently throws python errors when runN failed in compile.py. It throws error messages about it cannot parse stdout, stderr is not empty and runN does not return 0.
>> > Ideally, the check after runN should performed in the opposite order. stdout shouldn’t be parsed if runN does not return 0. Since it is expected that runN can fail during the test, g_log.error should be used to print the error instead of throw python error messages.
>> >
>> > Please commit for me after review.
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140625/4faa8d64/attachment.html>


More information about the llvm-commits mailing list