The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 48734 error_code 11 request_code 53 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.) I'm using GTK2 2.6.4-6 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051204 SeaMonkey/1.5a My testcase was the patch on bug 315207, with the LXR page for xpinstall/wizard/windows/dialogs.c - hovering over the tab resulted in the browser diappearing and the above message appearing in the console from which I launched it.

timeless helped me debug this error the other day. Here's a couple of tips: useful breakpoints: exit _XError _XDefaultError start with: ./run-mozilla.sh -g -d gdb ./seamonkey-bin --sync You might need to get symbols for xorg, to get more useful information. Also, if you download a debug xorg package make sure you uninstall it when you're done because xorg-dbg is compiled statically and does not allow module loading. (I found this out the hard way.)

the javascript from the patch does (effectively): ctx.drawWindow(win, 0, 0, 1487, 50660, "rgb(255,255,255)"); and Canvas happily attempts to allocate an offscreen 1487x50660 pixmap (which fails, of course).

I am experiencing this problem viewing http://movieweb.com/movies/galleries.php?film=2345&id=1903 Both Firefox 1.0.7 and 1.5 simply crash with the following: The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 38690 error_code 11 request_code 53 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.) I tried to debug it with ./run-mozilla.sh -g -d gdb ./firefox-bin --sync and all I get is: Program exited with code 01. (gdb) bt No stack. I'm running debian/sid, and testing with the 1.5 package from mozilla.com. I've plenty of memory available so that can't be it, and the site loads fine in Dillo and Opera. If I can provide more information let me know.

I believe the problem I am getting could be related to this bug. I notice a sudden decrease in available memory and a sudden increase in page file usage when trying to view a page with a huge canvas. (ie. 10000 by 10000) I have experienced this problem in Firefox 2.0, Seamonkey and Opera. I use the excanvas.js script to test it out under Internet Explorer 2.0. IE seems to render it fine without taking up that much of resources. I am guessing that there is a difference in the way VML renders the graphics. Cheers, Wayne

Can we get a Linux user with a trunk build to try this out again to see if it's still an issue?

The logic to compute the sizes for the tab preview canvas was actually changed before checkin, so one cannot easily crash like suggested in comment 0. So I saved the canvas painter example from http://caimansys.com/painter/index.html to disk and changed it so that is says <canvas id="colorChooser" width="275" height="40000"></canvas> Loading it the first time doesn't crash but when reloading it does (not with a BadAlloc but now with a BadPixmap): The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadPixmap (invalid Pixmap parameter)'. (Details: serial 76085 error_code 4 request_code 54 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.) Didn't manage to run it with the --sync option in the debugger, it then crashes already on startup.

I can't reproduce any crash or error with this. Even reloading multiple times; even replacing 40000 by 400000. works for me. Firefox 10.0a1 / debian wheezy / x86-64 / NVIDIA 275 driver