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 occurring.

We could do something similar to what we were doing for ObjC exceptions: http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsObjCExceptions.h http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/nsExceptionHandler.cpp#874 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.

Fixed off-by-one reported age an touched up some comments.

http://hg.mozilla.org/projects/electrolysis/rev/b1b8af0e01fe http://hg.mozilla.org/projects/electrolysis/rev/86e4bc5b4c4c

http://hg.mozilla.org/mozilla-central/rev/a5ba2b43122b http://hg.mozilla.org/mozilla-central/rev/9a4b73f92f0e

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/libxul.so +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: http://crash-stats.mozilla.com/report/index/d4a27184-fa09-41bb-8f55-a85bc2100302 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 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430