I have an aging X terminal which, after I ran the browser for long enough, starts to run out of memory. This initially manifests itself with BadAlloc errors, each accompanied by a BadDrawable, when attempting to display images. When this happens, the old 4.x browser simply displays blank where the image should be. Continuing to run it like that eventually causes the whole X server to crash, but I can always turn off loading images and keep going for as long as I want. Mozilla, on the other hand, can't handle this gracefully and crashes. Here is the debugger backtrace: Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 2405 error_code 11 request_code 53 minor_code 0 Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 2407 error_code 9 request_code 55 minor_code 0 [Switching to Thread 13059] Program received signal SIGSEGV, Segmentation fault. 0x40141758 in AddNullTerminator (aDest=@0x40eb2b84) at nsStr.h:488 488 aDest.mUStr[aDest.mLength]=0; (gdb) where #0 0x40141758 in AddNullTerminator (aDest=@0x40eb2b84) at nsStr.h:488 #1 0x400d0195 in nsStr::Truncate (aDest=@0x40eb2b84, aDestOffset=0) at nsStr.cpp:294 #2 0x400d54db in nsString::AssignWithConversion (this=0x40eb2b80, aCString=0x40e7c0b6 "Transferring data from ") at nsString2.cpp:1029 #3 0x40dde2e0 in ?? () from /grads2/cubranic/mozilla/mozilla/dist/bin/components/libnecko.so #4 0x40dddec0 in ?? () from /grads2/cubranic/mozilla/mozilla/dist/bin/components/libnecko.so #5 0x40dda760 in ?? () from /grads2/cubranic/mozilla/mozilla/dist/bin/components/libnecko.so #6 0x40ddf1a7 in ?? () from /grads2/cubranic/mozilla/mozilla/dist/bin/components/libnecko.so #7 0x40111b77 in nsThread::Main (arg=0x817d1f0) at nsThread.cpp:84 #8 0x40285b9b in _pt_root (arg=0x817d210) at ptthread.c:157 #9 0x402a1b85 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241

You didn't give a build date for the build you were using. Is it newer or older than May 12? If it is older than May 12, please confirm that it is fixed in newer builds and mark this bug as a DUPLICATE of bug 37212. If you still get the problem to occur, then reassign this to pavlov@netscape.com.

Sorry, I thought that kind of information got submitted automatically. Form that says "Some fields initialized from your user-agent, Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m16) Gecko/20000517." would certainly seem to imply so. Anyways, the build is May 17, so it's new enough. I don't believe this bug is the same as 37212 because the X error is different, in any case. Please note that this bug may be difficult to reproduce -- I only see it when running a small X server for long enough for it to leak sufficient memory to start having trouble when Netscape or Mozilla try to display images. Luckily ;-), I have it in just such a state right now, so let me know if additional debugger output is needed, and I'd be happy to get it for you.

Can someone please reassign this to pavlov@netscape.com, as David requested? Because when I try I get an error message saying "only the bug submitter, etc., can change the bug status". Never mind the fact that I *am* the bug reporter.

Clearing "probably dup of 37212" from Status Whiteboard, upping severity, adding crash kw. Assigning to pavlov as suggested by David, he might know best what to do here. Confirming bug since the report is well-written, a stack trace is attached, it is difficult to reproduce, and I have no doubt that this is real...

Davor: see bug 36905 for the problem with the permissions.

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

We can't spare the time & risk to address this bug in the current release. -> Future/helpwanted.

there are some things that we should do to try and avoid crashing in low mem situations (or when we're just too big).

Linux 2001041721 go to http://www.aftenposten.no/cgi-bin/top.cgi?./nyheter/okonomi/d204751.htm crash Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 22 error_code 9 request_code 55 minor_code 0

btw.. not an out of memory situation, least not physical: 512MB installed, of which 111 were free at time of crash. (in addition plenty of buffers and cached ram that could have been shuffled around, and 500MB unused swapspace.)

Also seeing this error at: http://antwrp.gsfc.nasa.gov/apod/ap010418.html on linux using 2001041808 with enough memory avail. This page consistently crashes the browser with output of: Document http://antwrp.gsfc.nasa.gov/apod/ap010418.html loaded successfully Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 17 error_code 9 request_code 55 minor_code 0 It looks like a java plugin download dialog box (I do not have it installed) pops up just before the crash. when I turn off Java page loads successfully.

faror@pacbell.net is right.. there's the plugin download window briefly appearing before the crash. What we're seeing is bug 76505.

*** Bug 76734 has been marked as a duplicate of this bug. ***

*** Bug 77392 has been marked as a duplicate of this bug. ***

I tried all the URLs mentioned with the April 30, 2001 build (build no. 2001043009) on linux (gtk 1.2.10) . The crash no longer occurs; perhaps its been fixed? I had a similar crash in GTK (76734) that is definitely fixed in recent nightlies; since this bug is marked as a duplicate of that, shouldnt this be fixed as well?

-> 0.9.4

-> 0.9.4

.

wfm

Having just moved back to a NCD ThinSTAR (a pretty braindead xterm running WinCE!) I can confirm this is still happening with IRIX build 2002011623 when trying to access www.webmethods.com Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 2890 error_code 11 request_code 53 minor_code 0 Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 2891 error_code 9 request_code 72 minor_code 0

I have just seen the same error on OpenVMS, and its reproducable: Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 18581 error_code 11 request_code 53 minor_code 0 Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 18583 error_code 9 request_code 70 minor_code 0 www.webmethods.com doesn't cause it for me. For me I see it when I: - go to bug 115819 - scroll down to comment number 23 - clicl on the attachment link - then click on BACK - BOOM! This is with 0.9.8 from about a week ago. This problem DOES NOT happen with the released 0.9.7 version. Its is definitely new. I'm doing a full 0.9.8 build now to see if the problem is still present, but that won't be done until tomorrow.

Hmmm, if I have the sidebar enabled then I can't get it to crash. Without the sidebar it crashes every time.

Still get the BadAlloc on my 0.9.8 build from 1/24/02. Takes 2 or 3 attempts before it crashes now though.

Nominating for 0.9.9, nsbeta1

*** Bug 124611 has been marked as a duplicate of this bug. ***

removing nsbeta1 nomination from keywords, since this has already been plussed by gagan.

tor/blizzard: what do you think about catching all X errors like 4.x did?

No, it papers over the real problems.

no, because in this case, they are running out of memory and don't have enough memory to allocate the image.. is there another way to figure this out before trying to allocate on the X server?

Is there a way to catch this specific X error?

This appears to be similar to, though not entirely unlike, a problem I have now seen on both HP-UX and Linux, which results in an error like: Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 860 error_code 11 request_code 78 minor_code 0 Gdk-ERROR **: BadColor (invalid Colormap parameter) serial 861 error_code 12 request_code 1 minor_code 0 So again, BadAlloc, though this case is BadColor rather than BadPixmap as started this bug report. I would assume that the root is the same -- memory allocation error leads to something (either pixmap or color) being invalid as allocated on the Xserver -- but I'm open to suggestion, if someone with more X knowledge would care to comment. I have seen this on all the 0.9.x versions I can remember trying, and more frequently recently on 0.9.9. In this case, Mozilla will run fine for days then mysteriously abort when drawing a new window. After the abort, the shell window where mozilla was started will show an error like the one above. No other X applications on the desktop appear affected by either the crash or by the resource problem which caused the crash, and mozilla can be started again fine afterwards. I have found that changing the amount of shared memory allowed to the X server does have impact on the amount of time between crashes. On HP-UX, this is configured to 6MB (GraphicsSharedMemorySize 0x580000 in /etc/X11/X0screens) by default, and tuning this up to 16MB allowed Mozilla to run several days without crashing. On 0.9.9, the crashes occur even with 16MB of X-server shared memory, and I've just tuned it up again to see if that will help. Note that compiling the gtk libraries to not use xshm (X shared memory extensions) also avoids this restriction, although it has the associated performance penalty. Restarting the X server with very little shared memory (setting /etc/X11/X0screen's GraphicsSharedMemorySize 0x10000) will prevent mozilla from even starting-up, which is where I got the cut-and-pasted error above. So the issues: - Can Gtk/Mozilla be written in such a way as to allow for an allocation falure and still keep running? In the above case, the allocation without attempted use of x-shared memory would have succeeded, for example. - There appears to be some sort of memory leak which allows mozilla to run fine for days, then suddenly hit a resource limit and fail.

FWIW, I don't have the shared memory support built into GTK on OpenVMS, and I see these BadAlloc/BadDrawable errors. Dan, are you X11 R5 or R6?

Hmmm... so much for narrowing it to shared memory -- maybe just generic memory allocation errors, then, of whatever type is most appropriately limiting for one's own particular X server. I'm running X11R6 on both Linux (2.4.2) and HP-UX (11.00) with GTK 1.2.10 (built on the same machine).

stack trace mentions necko. -> networking.

FWIW: The BadAlloc I reported in comment 21 does NOT occur on 1.0-rc1. At least that particular occurence of this problem appears to have been fixed.

Using xscope to trace allocations/frees, I was able to find a leak which I believe to have been the cause of my troubles: a bug in gtk+ versions through 1.2.10 causing a colormap leak. In gdk_window_new(), if creating a window on a non-default visual a colormap is allocated (reference count 1), but a reference is added to the window's colormap whether a new one was just created (reference count now 2) or whether another colormap is used. Colormaps allocated in this way will never be freed, as their reference count never goes below 1 when the window is destroyed. Eventually enough colormaps leak so as to run-out of memory on the X server, crashing Mozilla and allowing X to clean-up the resources. The cleanup was the first hint of a leak: the server would freeze for several seconds whenever Mozilla would exit. This leak appears to have been fixed in the X11 gdk_window_new code in the 2.0.2 version of the gtk library.

hmm, sounds like fun. We might be able to work around it somehow I suppose.

removing nsbeta1+... this bug is in GTK+ and I don't think I will get to this anytime soon. I would suggest those who are trying to use Mozilla on places where this is crashing fix the bug in GTK as Dan described in comment #36 and compile your own copy of Mozilla with this version of GTK. I will try to get together a patch that attempts to address this in Mozilla, but I wouldn't count on it anytime soon.

Dan, cab you tell me exactly what needs changing in gtk_window_new()? I'm very interested in trying this fix on OpenVMS (running GTK+ 1.2.8).

Sure: straightforward fix as excerpted here from gdk/gdkwindow.c in gtk 1.2.10, much the same on other gtk 1.2 patchlevels, I believe, and based on the changes in the X11 portion of version 2.0.2 (gdkwindow-x11.c), if you want to compare: gdk_window_new(){ [ ... ] if (attributes->wclass == GDK_INPUT_OUTPUT) { class = InputOutput; depth = visual->depth; if (attributes_mask & GDK_WA_COLORMAP) { private->colormap = attributes->colormap; gdk_colormap_ref(private->colormap); // add this line and brackets } else { if((((GdkVisualPrivate*)gdk_visual_get_system ())->xvisual)==xvisual) { private->colormap = gdk_colormap_get_system (); gdk_colormap_ref(private->colormap); // add line and brackets } else private->colormap = gdk_colormap_new (visual, False); } [ ... ] } else { depth = 0; class = InputOnly; private->colormap = gdk_colormap_get_system (); gdk_colormap_ref(private->colormap); // add this line } private->xwindow = XCreateWindow (private->xdisplay, xparent, x, y, private->width, private->height, 0, depth, class, xvisual, xattributes_mask, &xattributes); gdk_window_ref (window); gdk_xid_table_insert (&private->xwindow, window); /***** delete these lines if (private->colormap) gdk_colormap_ref (private->colormap); *****/ [ ... ] }

Three times in the last two days, I've crashed with 1.1 trunk (2002072508): Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 164 error_code 9 request_code 144 minor_code 3 These are the only crashes I've had in months, and they aren't triggering talkback. This is probably a huge topcrash issue. I wasn't getting these before recently. This most recent time it happened while submiting the bablefish form.

Here is Dan's suggested fix as a patch against GTK+ 1.2.10.

*** Bug 191861 has been marked as a duplicate of this bug. ***

adt: nsbeta1-

Mozilla 1.5a Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_617_MHz; en-US; rv:1.5a) Gecko/20030721 Here is a URL that is reproducing this crash every time I try it: http://mainbyte.com/coco/coco2_mb.jpg Starting MOZILLA-BIN... EAGLE::_FTA20: 22:44:03 MOZILLA-B CPU=09:10:08.82 PF=1782670 IO=195400826 MEM=4599 Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 173944 error_code 11 request_code 53 minor_code 0 %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000007A1830, PC=FFFFFFFF80BDA9E4, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC 0 FFFFFFFF80BDA9E4 FFFFFFFF80BDA9E4 0 FFFFFFFF80BDA858 FFFFFFFF80BDA858 LIBGDK GDK gdk_x_error 22209 0000000000001690 00000000001F9690 0 FFFFFFFF80C2C07C FFFFFFFF80C2C07C 0 FFFFFFFF80CAFCB4 FFFFFFFF80CAFCB4 0 FFFFFFFF80C28ED8 FFFFFFFF80C28ED8 0 FFFFFFFF80BEAAD4 FFFFFFFF80BEAAD4 0 FFFFFFFF80C4040C FFFFFFFF80C4040C LIBGDK GDK gdk_exit_func 22172 0000000000001610 00000000001F9610 0 FFFFFFFF8007A0D4 FFFFFFFF8007A0D4 PTHREAD$RTL 0 0000000000055194 000000007BD31194 PTHREAD$RTL 0 000000000003EDCC 000000007BD1ADCC PTHREAD$RTL 0 000000000002C2B0 000000007BD082B0 0 0000000000000000 0000000000000000 PTHREAD$RTL ? ? 0 FFFFFFFF8025FE94 FFFFFFFF8025FE94 I have do not have any plug ins installed, and this page does not request any.

FWIW, this does not crash my 1.4 (vanilla milestone build) on i686/Linux -- but it is a rather large jpeg file: 3MB file, expanding to 3508x2551 pixels at 4 bytes each (assuming 24 bit color + alignment) is 35MB all by itself. Watching here with top on this version, Mozilla grew to about 60MB RSS before the image was completely shown. Could be a simple out-of-memory issue for either mozilla or the X server or X-server shared-memory in your particular configuration, rather than a leak: as you say the problem surfaces immediately, rather than running-out of memory slowly over time, as did the problem I discovered here earlier.

re: comment 45 John, I can display that TRS-80 board just fine using Mozilla on my OpenVMS system. It does take a good chunk of the X server' memory though, about 70,000 pages. In the OpenVMS Mozilla release notes (http://h71000.www7.hp.com/openvms/products/ips/mozilla_relnotes.html) the BadAlloc problem is explicitely called out, and it is suggested that you increase your server's VM to 200,000 pages. Have you done that?

I am at 270000 pages for the pagefile quota. I have also switched to the CDE desktop to try it out. The extra desktops probably require more pagefile quota for the server. Peak virtual size for the decw$server_0 process is 470176. So it looks like 270000 is still not enough since I only have 256 M of physical memory. WSMAX is limited to 250000 pages. For the server process, the WSEXTENT value is limited to WSMAX. It still would be nicer to have Mozilla handle this condition more graceful I am also not getting any notifications from Bugzilla about this bug number and others, including confirmations of my submits, I just happened to look at it again. I have added myself as a CC:, but I have never had to do this before. So if there are any that have not responded to, please let me know.

Increasing the page file quota to 1000000 allows me to view the TRS-80 board. With just a few Mozilla windows displayed, including the TRS-80 board, it is using 315168 pages.

> It still would be nicer to have Mozilla handle this condition more graceful Absolutely agree. It appears that GDK is trying to exit gracefully, but then falling flat on its face. I'll see if I can find out what's tripping it up.

First, this isn't a Mozilla issue, its a GDK (part of GTK+) issue. And second, the GDK code is pretty much done when the accvio happens. Its in its atexit handler where the error message gets printed where the problem occurs. I've tried but although I can reproduce the gdk error, I can't reproduce the accvio on my system: $ @mozilla Starting MOZILLA-BIN... Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 8720 error_code 11 request_code 53 minor_code 0 $ @mozilla Starting MOZILLA-BIN... Gdk-ERROR **: BadAlloc (insufficient resources for operation) serial 126160 error_code 11 request_code 53 minor_code 0 $ I suspect its a "glitch" in the pthreads or crtl library. Or maybe one of the DECW libraries. Anyway, Mozilla and GDK appear to try and handle the X error gracefully.

Colin, Can you try it on OpenVMS 7.3-2 EFT, and on the SSB canidate releases? I am also having Mozilla crash every time a plugin exits. It may be related.

> Can you try it on OpenVMS 7.3-2 Sorry, the latest I have is 7.3-1. Can you mail me a log of the crash which occurs when a plugin exits.

For newbies (like me) suffering this bug, a workaround that seems to work is to up the limits in /etc/login.conf, at least this works on FreeBSD 4.9 Release with Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030827. Before that, I could barely open three tabs before getting 11/53 crashes. With the limits upped to unlimited, twenty tabs full of intensive graphics pages seems fine. I realise that there's still probably some nasty memory leaks going on as it takes less and less time for mozilla to crash within a single X session until X is restarted but I'll leave that for others who know what they're talking about :-).

I'm seeing this also with firefox v0.8. I recently added a "ulimit -v" command to my .bashrc to try to keep mozilla/firefox and other processes from going crazy and running me out of swap every once in a while and things seemed to be working better for a bit, but then I started getting seemingly random crashes. Turned out to be dying with a BadAlloc error. It's pretty easy to duplicate. Run "ulimit -v 131072" before starting X and then load a page with a lot of large inline images. When the X server can't allocate more memory, mozilla/firebird dies.

Just to report that this problem is still occurring with the current Firefox (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 ). I haven't seen it myself, but 2 students have reported identical symptoms when running Firefox on NCD Explora X terminals. Firefox crashes frequently (no bug-report dialogue, it just crashes) with the following messages: 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 56057 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() I plan to increase the memory in the terminals from 16 to 32 MB to see if it helps, but I do feel the software should deal more gracefully with limited resources. After all, if you believe all the hype then one of the biggest selling points of Linus is its ability to work on old equipment.

I have been given a fairly reliable procedure for reproducing this bug on an NCD Explora with 16 MB of memory: 1. Visit http://www.digitalblasphemy.com (this is a digital art site). 2. Click on "Enter Here" (middle of the page) 3. Click on "free gallery updated" (middle-left) 4. Click on the picture above "gazebo 2003" (upper right) 5. Go Back 6. Click on the picture above "once upon a time" (upper right) 7. Go back 8. Click on the next picture down Firefox then crashes as in my previous message.

we already have bugs against NCD, if that's what you're all testing agianst, then i request someone mark this bug as DUPEME or dupe it. Otherwise, those of you complaining about NCD are in the wrong bug.

(In reply to comment #58) > we already have bugs against NCD, if that's what you're all testing agianst, > then i request someone mark this bug as DUPEME or dupe it. Otherwise, those of > you complaining about NCD are in the wrong bug. I don't think I understand your comment: could you be more explicit? I found 5 bugs which mention NCD and none of the others looks to me like a duplicate of this one. Which one do you have in mind? I don't think the NCD X server is to blame; it truthfully reports a memory shortage but the X client is unable to handle the situation and crashes.

(In reply to comment #59) > (In reply to comment #58) > > we already have bugs against NCD, if that's what you're all testing agianst, > > then i request someone mark this bug as DUPEME or dupe it. Otherwise, those of > > you complaining about NCD are in the wrong bug. > > I don't think I understand your comment: could you be more explicit? I found 5 > bugs which mention NCD and none of the others looks to me like a duplicate of > this one. Which one do you have in mind? > > I don't think the NCD X server is to blame; it truthfully reports a memory > shortage but the X client is unable to handle the situation and crashes. Just encountered this bug, using Firefox 1.5 Following procedures, I downloaded/installed latest Mozilla: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050702 Trying website - http://www.movieweb.com/movies/film.php?2791 consistently crashes Fx, in normal and safe mode, and fresh version of Moz, with noted BadAlloc/BadDrawable Gecko error. Restating what others have mentioned, I doubt this is a low memory issue, as I have 1G Ram on this box. Also, Konqueror and Epiphany browsers are unaffected, if that's any help.

Can we assume that you're building against GTK2? The leak I found (comment 40) was in the stable gtk 1.2 branch, and so was never patched there by the GTK folks, as it was patched in the current GTK2 library instead. If you're still building against a stock GTK1.2 library, you could still be hitting the same bug, and would require the GTK patch attached here, but I'm guessing that most are building against GTK2 these days. Of course, one might argue that the bug which still exists in moz/gecko/etc is that the resource errors are not handled more gracefully. It's certainly been the tack so far that avoiding the resource errors is the top priority, but cleaner error handling would probably avoid this sort of confusion. Bottom line, the error here results from bad reuse of X resources, which could be anything from using an X resource after a free to simply running out of memory on the X server. As you state that your box has a decent amount of memory, it *shouldn't* be running out of X resources, but if there's some runaway allocation of X resources going-on, the amount of memory wouldn't generally prevent a problem. If you watch the FireFox client app, does it appear to grow in memory size to something giant when you view this page? Also, can you think of any unique configuration in the display which would trigger this bug on your machine and not others? Any atypical color map or display setups?

Is this the same problem as bug 321741 and if so, should they be merged?

I get similar crashes a couple of times a day, but have yet to notice a correlation with a particular site. Here's a C&P of the lastest one: The program 'firefox-bin' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 19045088 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 on FreeBSD 6.0-RELEASE using Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8) Gecko/20051228 Firefox/1.5 built from ports. This is linked against GTK2, which is shown as current by portversion, which means 2.8.10.

*** Bug 321741 has been marked as a duplicate of this bug. ***

*** Bug 330366 has been marked as a duplicate of this bug. ***

i know this bug is old, but it's not worth keeping it alive, i'm sorry. *** This bug has been marked as a duplicate of 210931 ***