Closed Bug 796328 Opened 12 years ago Closed 12 years ago

mochitest-4 logs are too large

Categories

(Testing :: Mochitest, defect)

Product:
Testing
Component:
Mochitest
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(firefox17 unaffected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox17 --- unaffected

People

(Reporter: philor, Unassigned)

References

(Blocks 1 open bug)

Details

https://tbpl.mozilla.org/php/getParsedLog.php?id=15707176&tree=Mozilla-Inbound is a Windows debug mochitest-4 which went just fine, except that it hit a shutdown timeout, so we put a screenshot in the log, and then would have wanted to put a stack in the log (and we would have failed, because we haven't been able to kill Windows jobs for *years* now), except buildbot cut off the log partway through the screenshot. A screenshot and a stack is more than the headroom left under buildbot's 50MB log limit. It was already a problematic hunk (the last bunch of imported DOM tests have to silently run 100 tests and then output "hey, I ran another hundred", and when we've had failures in that hunk that required opening full logs, I ran up against my bandwidth quota, and it's hit-or-miss whether tbpl will load one without timing out), but not being able to put in a screenshot and a stack is a pretty clear sign it's time to do something. I wanted to just add mochitest-6, because that's easy enough that I can do it, but it won't really help. Running locally in an opt build, just for comparison-sized numbers, I get a 42.6MB log from the existing M4/5, and a 40.4MB log from M5/6, that being where layout/, and particularly layout/style/, go. If we really need to have nearly 40MB of logs from the CSS mochitests, and can't just quiet them down to only saying "hey, there went another 100 properties without a failure," the only other solution I can think of is to move them into their own mochitest-css, where they can have all of 50MB, and nobody else has to alter their output to let them spew freely.
Blocks: logspam
Hey, dom/imptests lived in M2 last time I checked.
Right you are - imptests never would have fit in M4, I just got thrown off by seeing dom/tests/mochitest/whatwg/ fly by. It's only dom/tests/mochitest/w* and editor, intl, js, and the rest of layout having to share space with mochitest-css.
Depends on: 797645, 797649
3 megs of the M4 log is a silly data URL being logged.
I did some analysis, and it looks like between bug 797827 and bug 797649 most or all of the really long lines (>500 chars or so) will be eliminated from M4.
I looked at a green M4 log, with bug 797827 and bug 797649 fixed. The size was down to 32MB, which is sounds like it is about 10MB better.
With some crude grepping, about 28.9MB of the remains is TEST-PASS lines, 1.6MB is WARNING lines, 1MB is ++--DOMWINDOW stuff, 380k is KNOWN-FAIL, 71k is ++--DOCSHELL stuff. Those categories account for something like 99% of the file.
Is this only a problem in Fx18? Do we need to backport bug 797827 and bug 797649? They are debug- or test-only so it shouldn't be a big deal.
Depends on: 630242
(In reply to Andrew McCreight [:mccr8] from comment #12) > Is this only a problem in Fx18? Do we need to backport bug 797827 and bug > 797649? They are debug- or test-only so it shouldn't be a big deal. Just 18, though I have backported bug 797827 to 17 since it's a quick log size (thus hangs and TBPL database bloat) win - and is covered by the blanket a=test-only, unlike bug 797649.
Sure, but it would be easy to get approval for bug 797649 since it is debug-only. But if there's no immediate problem in 17 we can just leave it alone. Can this be closed as fixed? We haven't had any failures for a week, since bug 797827 landed. Any further work could just go in bug 765224.
status-firefox17: --- → unaffected
Though I guess I might as well land it there, since as you point out ESR17 is going to be with us for a long time...
Requested approval; closing this as all done here :-)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.