Closed
Bug 427480
Opened 15 years ago
Closed 14 years ago
Unsuckify error reporting when reftest/crashtest harness crashes
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Waldo, Unassigned)
References
Details
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1207545360.1207548052.31482.gz&fulltext=1 No errors printed, every reftest that ran passed, but reftest crashed, and there's no obvious sign that it did except for scrolling to the end of the reftest execution and noting: REFTEST PASS: file:///builds/slave/trunk_centos5/mozilla/layout/reftests/bugs/375827-1.html (Gecko:8694): Gdk-CRITICAL **: gdk_drawable_set_colormap: assertion `cmap == NULL || gdk_drawable_get_depth (drawable) == cmap->visual->depth' failed (Gecko:8694): Gtk-CRITICAL **: gtk_paint_box: assertion `style->depth == gdk_drawable_get_depth (window)' failed The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 532636 error_code 8 request_code 70 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) TinderboxPrint: reftest<br/>661/0/21 Not how to change the code to fix this; the relevant stuff is at: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/tools/buildbot-configs/testing/unittest/mozbuild.py&rev=1.18&mark=409-411#377 Maybe stash status in an instance property or something and check it in createSummary?
Updated•14 years ago
|
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: Trunk → other
Comment 1•14 years ago
|
||
AFAIK, nobody from RelEng will be working on this soon.
Component: Release Engineering → Release Engineering: Future
Comment 2•14 years ago
|
||
I think this isn't an issue since 483111 landed - what do you think Jeff?
Reporter | ||
Comment 3•14 years ago
|
||
Agreed, fixed by bug 483111.
Comment 4•13 years ago
|
||
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Assignee | ||
Updated•9 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•