Closed Bug 678688 Opened 11 years ago Closed 11 years ago

getParsedLog.php?full=1 doesn't work for mochitest-other logs


(Tree Management Graveyard :: TBPL, defect)

Not set


(Not tracked)



(Reporter: philor, Assigned: mstange)



(4 files)

Guessing wildly, but while random other sorts of logs like reftests and builds work just fine, mochitest-other logs like are empty, like they're hitting a resource limit, or a surprisingly fatal PHP error or something. Minus the &full=1, works fine, but does not, since it was a green mochitest-other, so brief is full.
both work, so maybe it is a memory limit problem. I have a limit of 256 on my server. I guess it can be bumped to 512M on production.
Unless the production server ignores our .htaccess php_value overrides, memory shouldn't be the problem... but php execution time might well be.
Assignee: nobody → mstange
Attachment #552848 - Flags: review?(arpad.borsos)
Empty arrays are falsy values, so logs without errors were effectively parsed three times.
Attachment #552849 - Flags: review?(arpad.borsos)
This doesn't affect performance but makes it slightly clearer where time is spent when looking at profiles.
Attachment #552850 - Flags: review?(arpad.borsos)
This is approximately what the profile looks like. It's not accurate because xdebug adds its own overhead, and because when I made this profile I had to comment out all preg_match lines except for two in GeneralErrorFilter::matchLine to get the execution to finish at all.
Maybe it would be a good idea to port the log parsing code to python and see what difference in performance it makes.
Attachment #552848 - Flags: review?(arpad.borsos) → review+
Attachment #552849 - Flags: review?(arpad.borsos) → review+
Comment on attachment 552850 [details] [diff] [review]
part 3: break up FullLogGenerator::getLog into parts

Review of attachment 552850 [details] [diff] [review]:

Much easier to read too, thanks.
Attachment #552850 - Flags: review?(arpad.borsos) → review+
nthomas pulled those to allizom, and still seems a wee bit light on content.
nthomas, can you tempararily remove these lines from the .htaccess:
php_value error_reporting 0
php_value display_errors 0
and paste the error that prints (if any) here?

This isn't a good debugging situation. Maybe we should add parameters that turn on PHP error reporting again?
The server returns a 500, and the Apache error log has:

[Mon Aug 15 16:29:45 2011] [error] [client] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 22507435 bytes) in /var/www/
tinderboxpushlog-staging/php/inc/FullLogGenerator.php on line 36

There are earlier entries in the staging log like that, so it's possible the .htaccess isn't being used. I'll take a look at the Apache config.
I've gotten so used to clicking in the blank space where our SVG close button isn't on the timeout alerts that I'd forgotten that I already knew .htaccess was being ignored on tbpl.allizom just like it is on tbpl.mozilla
The .htaccess files work on both tbpl.mozilla and tbpl.allizom now, and the log in comment #10 loads.
(In reply to Nick Thomas [:nthomas] from comment #13)
> The .htaccess files work on both tbpl.mozilla and tbpl.allizom now

Cool, I'll close bug 663593.
Deployed via bug 683241
Closed: 11 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.