[Tbox server] Windows error parser needs to support gmake errors

Assigned to


Webtools Graveyard
10 years ago
12 days ago


(Reporter: nthomas, Assigned: morgamic)




(1 obsolete attachment)



10 years ago
Many times I go to load a Brief Log from a tinderbox waterfall page, and get the full log instead. This can take a long time to download (more than 7 MB for a win32 clobber build at ~ 70 KB/s), and usually I'm only interested in the error or BuildID contained in the last 1000 lines or so.

Can this be made more robust ? It seems to be related to error detection that fails (see example below) - even if the build reported success, a brief log (eg tail -1000) would be preferable. A quick check didn't find any connection between builds which are log scraped (or not) and this issue.

Steps to reproduce
1, Load http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1185887040.20965.gz

Expected results: get error summary (this build was "busted") that downloads quickly

Actual results: get full log that takes a while to get to the interesting bit.

Comment 1

10 years ago
The root of the problem appears to be that the error parser isn't seeing the errors as errors.  Since the windows builds switched to using gmake many years ago, the tinderbox's error parser for windows builds hasn't been updated to support gmake errors.  

Since Mozilla no longer users nmake or codewarrior, I'm wondering if we shouldn't just consolidate the error parsers into a single one.  We could still use the errorparser setting to look for platform/tool specific errors.

Summary: [Tbox server] Brief logs requests often served full ones → [Tbox server] Windows error parser needs to support gmake errors

Comment 2

10 years ago
I don't think this is a windows only issue though, here are mac & linux builds with the same problem.


And this windows trunk works ok:


Does that fit with a broken error parser hypothesis ?

Comment 3

10 years ago
There are 2 scenarios mentioned in the original report.

Case 1:  There's an error that's not caught by the error parser.  That's what the original log showed.  That's due to a bug in the parser.

Case 2:  There's no error so the brief log shows the entire log because there's no reason to highlight any portion of the logfile by shortening it.  That's the standard behavior.  

The mac & linux builds are examples of case 2.  The second windows log "works" because there were warnings which were caught by the windows error parser, so you got the shortened log even though it looks as though the windows build succeeded.
Product: Webtools → Webtools Graveyard
Created attachment 8926193 [details] [diff] [review]
Get LCOV stats for first line of script, and handle lines that belong to more than one script
Comment on attachment 8926193 [details] [diff] [review]
Get LCOV stats for first line of script, and handle lines that belong to more than one script

Sorry, mess-up with 'hg bzexport'
Attachment #8926193 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.