Unsuckify error reporting when reftest/crashtest harness crashes

RESOLVED FIXED

Status

RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: Waldo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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?
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: Trunk → other
AFAIK, nobody from RelEng will be working on this soon.
Component: Release Engineering → Release Engineering: Future
I think this isn't an issue since 483111 landed - what do you think Jeff?
(Reporter)

Comment 3

10 years ago
Agreed, fixed by bug 483111.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Depends on: 483111
Resolution: --- → FIXED
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.