Closed Bug 517133 Opened 10 years ago Closed 10 years ago

Get crash stats for X errors


(Toolkit :: Crash Reporting, defect)

Not set



Tracking Status
status1.9.2 --- .4-fixed


(Reporter: karlt, Assigned: karlt)


(Whiteboard: [fixed-lorentz])


(1 file, 1 obsolete file)

Often enough we get reports of X errors.  It would be nice to get some stats
to indicate which of these are causing frequent problems.  Currently GDK's
X error handler prints some helpful data to standard error and exits with
status 1.

We could get a first indication of where these errors are occurring using
XSetErrorHandler in nsAppRunner to set up a handler that calls abort() instead
of exit() after printing similar data.  Using abort would also often be more
helpful than exit even in non-crashreporter-enabled builds, to make getting a
stack easier.

Eventually it would be even better to be able to report the error code and
request type code.  (These are asynchronous errors, but enough X operations
require round trips that it is usually not too long before the error is
detected.)  This doesn't seem to be to different from CRT invalid parameter
handler reports (see bug 397199), so maybe something similar could be used.
Bug 510505 also looks like it would provide a way to do this.

Some might argue that we should attempt to continue from X Errors (bug 348463
and bug 210931).  I'm not sure how well this would work as GTK (and Mozilla)
are probably not expecting to continue after errors.  If we do try to continue
in release builds we should still catch these errors in debug builds.
However, the first stage is probably to get data on how often these errors are
We could do something similar to what we were doing for ObjC exceptions:

AppendAppNotesToCrashReport will append an arbitrary string to the "Notes" field of the crash report, which will be displayed on crash-stats. The ObjC exception handling code would do that and then abort.
Please yes.  I've been triaging Linux crash bug reports and a lot of them are X errors.  We're missing a lot if we don't get crash reports for X errors.
Attached patch for browser and plugin processes (obsolete) — Splinter Review
Attachment #428757 - Flags: review?(benjamin)
Attached patch v1.1Splinter Review
Fixed off-by-one reported age an touched up some comments.
Assignee: nobody → karlt
Attachment #428757 - Attachment is obsolete: true
Attachment #428757 - Flags: review?(benjamin)
Attachment #428769 - Flags: review?(benjamin)
Attachment #428769 - Flags: review?(benjamin) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre

Is this what causes errors which contain paths from the build machine? I just got a terminal message which refers to a file on moz2_slave, and I'm using a pre-built nightly. I'm not sure if this is expected or not (the path), so I'm reporting it here. The bug itself is something I can file separately I wanted, although I don't know what was occurring when the message appeared...

(<unknown>:8295): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed

(<unknown>:8295): Gdk-WARNING **: GdkWindow 0x2600003 unexpectedly destroyed
###!!! ABORT: X_ChangeProperty: BadWindow (invalid Window parameter); 26 requests ago: file /builds/moz2_slave/mozilla-central-linux-nightly/build/toolkit/xre/nsX11ErrorHandler.cpp, line 182
UNKNOWN [/home/djc/firefox-3.7a3pre.en-US.linux-i686/firefox/ +0x001F00CF]
(In reply to comment #7)
> Is this what causes errors which contain paths from the build machine?

> ###!!! ABORT: X_ChangeProperty: BadWindow (invalid Window parameter); 26
> requests ago: file
> /builds/moz2_slave/mozilla-central-linux-nightly/build/toolkit/xre/nsX11ErrorHandler.cpp,
> line 182

The changes here caused this error to be reported through NS_RUNTIMEABORT.
Other errors will also go through NS_RUNTIMEABORT.  It is NS_RUNTIMEABORT that is printing the paths from the build machine and the stack.

The error messages look like bug 540114, but that should be fixed in the 20100301
build, so if you are seeing those messages in recent builds then we have another bug that we need to fix.

If you would be willing to submit crash reports then we can at least find out which plugin is crashing.
Edit -> Preferences -> Advanced -> Submit crash reports

And if you manage to find steps to reproduce, then repeating with MOZ_X_SYNC=1 in the environment would be helpful.
Submit crash reports was already checked, but I didn't realise that a crash report had been created because there was no indication of this. I just saw 2 mozilla-runtime processes with status "Zombie" in the Gnome System Monitor and killed Minefield myself as it wouldn't respond. Opening about:crashes I could see that there was a crash, but it was pending, so I submitted it and here it is:

I think I was closing a YouTube tab. I will try and reproduce in a clean profile, and if so I'll file a new bug.
Thanks, Daniel.  It sounds like the browser didn't complete processing of the child process crash (as it hung for some unknown reason), so the crash report doesn't actually tell us which plugin it was.

If you manage to reproduce, a new bug report would be great, thanks.
If you kill -ABRT <the-firefox-process> when it hangs, we might be lucky enough to get a crash report with a stack trace.
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for - please make sure to mark status1.9.2:.4-fixed
You need to log in before you can comment on or make changes to this bug.