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

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Tinderbox, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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

[cls]

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.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

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

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1185901320.12080.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1185903480.15727.gz

And this windows trunk works ok:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1185902580.14501.gz

Does that fit with a broken error parser hypothesis ?

Comment 3

[cls]

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.

Comment 4

[Philip Chimento [:ptomato]]

Attachment: Get LCOV stats for first line of script, and handle lines that belong to more than one script

Comment 5

[Philip Chimento [:ptomato]]

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'

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Tinderbox isn't maintained anymore. Closing.