Firefox crashes upon loading specially crafted PNG file (remote DoS attack)

[PowerUser]

Binary package hint: firefox

Firefox could be crashed by a remotely-triggered DoS condition causing very unpleasant user experience.

Prerequisuites:
 Firefox 3.0 running under some X Window system. At least x86 and AMD64 Ubuntus are affected.

To reproduce:
 Either load URL like http://lady.mail.ru/img/bg_l.png or open attached file in Firefox

Result:
 Firefox immediately terminated. This allows people to play a bad joke against non-windows OS users causing DoS condition by attempt to load a bad PNG file.

Output:
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 345764 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.)

Notes:
 Upstream haves a bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=210931 and encourage them to fix this bug ASAP.

[S-a-moeller (s-a-moeller)]

Created an attachment (id=126641)
Testcase

[Bugzilla-accessibleinter (bugzilla-accessibleinter)]

WFM 20030627 PC/WinXP

[S-a-moeller (s-a-moeller)]

This is the error message I get:

Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with
width 36906 and height 11306
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
  serial 16837 error_code 11 request_code 53 minor_code 0

[Olivier Cahagne (wolruf)]

wfm using Firebird 20030626 on WinXP.

[Tenthumbs (tenthumbs)]

Crashes my Linux trunk build. It looks like GTK gets very upset and aborts the
process.

[Tenthumbs (tenthumbs)]

Created an attachment (id=126647)
stacktrace

Loading the attachment.

[Mitch (mitch-hasbox)]

Interesting. This happens on gtk1 and gtk2 builds since in gdk.c we set
the error handler using XSetErrorHandler() to an internal handler which
prints out the error message and exits. Unfortunately this means mozilla
can never catch this error and infact can't get to it's errorhandling
code

  XImage *ximage = XGetImage(dpy, drawable,
                             readX, readY, readWidth, readHeight,
      AllPlanes, ZPixmap);

  NS_ASSERTION((ximage!=NULL), "XGetImage() failed");
  if (!ximage)
    return;

The only way i see round this is to reset the errorhandler after the
gdk_init/gtk_init to either a mozilla handler to handle X errror or set
it to NULL so no handler gets called and we can get to the errorpath
if (!ximage). I think the former proposition is better.

[S-a-moeller (s-a-moeller)]

I've changed the summary, because

a) The true cause of this bug is not the javascript being malformed (mixing up
arithmetical operation and string concatenation) but the large number resulting
from that malformed term.

b) This can lead to much more serious problems. If the width and heigth
parameters are extremely large (~100000, as in my testcase), Mozilla simply
crashes (not too dangerous). But with somewhat smaller values Mozilla seems to
allocate endless amounts of memory, rendering the whole system unusable.

I've tried

  window.open('','win','width=10000,height=10000');

and the only way to get out of it was to kill the X server.

[Mitch (mitch-hasbox)]

Stefan that's not a problem with mozilla that a client should not
be allowed to allocate a large amount of memory. You can get round that by
setting you limit/ulimit correctly in the shell. And anyhow, as i said
in my previous comment - mozilla will not be able to catch this error
of allocation failure since it is handled by the UI library (gtk/gtk2)
which calls exit instead of letting mozilla handle the error correctly.

So what i'm saying is that even limiting your stack in the 'mozilla' script
so the Xserver doesn't consume all the memory, we *still* will not be
able to catch the allocation error and handling it differently unless we
reset the errorhandler with our own one.

[Mitch (mitch-hasbox)]

A more descriptive Summary would be

 Mozilla should reset the X error handler to trap overallocation failures in
gtk/gtk2 libraries

[Olivier Cahagne (wolruf)]

does it still happen with latest nightly build ?

[Ajschult (ajschult)]

still crashes with linux trunk 2004011007

[Mitch (mitch-hasbox)]

Created an attachment (id=164302)
patch to catch the error rather than disappearing.

Guys, this patch has been sitting in my folder for a while, so here it is in
all its glory which fixes both this bug and bug 267126 - the latter brought it
back to my memory banks.

Basically we use the gdk helper functions to catch the error instead of just
killing mozilla. We can then provide any form of dialog to warn the user that
the page will not be rendered as expected due to memory allocation faliure as a
result of bad html/javascript code. Currently (this patch) no user feedback is
given. We can do one of two things.

1. Warn that the page will not be rendered as expected and carry on as best we
can perhaps resizing image/window to sensible values not larger than screen
real estate, or

2. Abort the page loading totally - i.e. don't display a partially (in)correct
page, and provide user feedback to that effect ?

Comments before submitting for sr/r ?

[Ajschult (ajschult)]

gtk

[Ajschult (ajschult)]

Mitch: can you create a unified diff patch (diff -u), preferably from CVS?

[Mitch (mitch-hasbox)]

Andrew, i'll do this later today. I want to clean it up slightly and provide a
feedback dialog. Will attach a unified cvs diff as requested.

[Mitch (mitch-hasbox)]

Created an attachment (id=164835)
Slightly modified testcase to trigger bug 267126

Here is a slightly modified testcase to trigger this bug (for testing
purposes). It will not work on anything but mozilla/firefox since it uses a URI
resource:/res/broken-image.gif as a test image so it could be a standalone
testcase.

Patch to follow.

[Mitch (mitch-hasbox)]

Created an attachment (id=164836)
New patch for review

unified patch against today's cvs.

[Ajschult (ajschult)]

(From update of attachment 164836)
Mitch: you can get a diff from CVS with "cvs diff -u filename.cpp"

[Mitch (mitch-hasbox)]

Created an attachment (id=164860)
As requested by Andrew.

P.s. I changed my mind about the user dialog feedback (comment #16 and #13)
since we would be in a catch-22 situation if i tried to poup a dialog if we are
already into memory allocation failure hell. So the patch only does fprintf to
stderr now.

[Kherron+mozilla (kherron+mozilla)]

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

[georgi (guninski)]

dveditz, this may be overflow but i can't get a stack.

testcase on the web is in bug 267126

[Mitch (mitch-hasbox)]

Georgi how many times do i need to explain. There is no stack ! Mozilla is
exiting as designed (by the X library default handler). What are you expecting ?

[Blizzard (blizzard)]

(From update of attachment 164836)
I'm not doing reviews at the moment, this should probably go to roc.

[Roc-ocallahan (roc-ocallahan)]

I think the correct way to fix this is to put in a higher-level check on window
sizes to stop pages trying to create too-large windows.

[Timeless-bemail (timeless-bemail)]

(From update of attachment 164860)
roc: there's no guarantee that any given size will work, the xserver could just plain not have memory.

[Bzbarsky (bzbarsky)]

What are the performance implications of all those gdk_flush calls, if I might ask? Those sound like a perf nightmare, especially with a non-local X server...

[Timeless-bemail (timeless-bemail)]

Created an attachment (id=202942)
updated for merge conflicts

[Adam Guthrie (ispiked)]

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

[Roc-ocallahan (roc-ocallahan)]

can someone address comment #27?

[Timeless-bemail (timeless-bemail)]

well, i'm not sure, it'd be nice if someone who has a profiler available could test it and find out (preferably 4 profiles: unpatched local server, unpatched remote server, patched local server, unpatched remote server).

i'm expecting they're fairly bad. in which case i'm willing to add code which only calls flush if we can detect that the server is local or a certain pref/env var is set. i'll only do this if someone is willing to accept that change. basically it would mean that users who don't want to crash, or who won't get much of a perf penalty would be protected by this code and people who would get a performance hit would have to opt for it or retain their current crashable state.

i think that minimo would want this :).

[Roc-ocallahan (roc-ocallahan)]

The other thing is that this code is going away in 1.9 so it may no be worth spending time on.

[Timeless-bemail (timeless-bemail)]

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

[Adam Guthrie (ispiked)]

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

[Chris Thomas (CTho) (cst-yecc)]

(In reply to comment #28)
> Created an attachment (id=202942) [edit]
> updated for merge conflicts
>

This does not seem to fix bug 319235.

[Adam Guthrie (ispiked)]

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

[Adam Guthrie (ispiked)]

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

[Ajschult (ajschult)]

Created an attachment (id=205126)
include other gdk_pixmap_new callers

this handles the problem from bug 319235. It also seems that gdk_draw_pixmap is not going to have the problem we're seeing here since it shouldn't allocate memory and there seems to be only one crashe in b.m.o with gdk_draw_pixmap and it's a real crash.

[Adam Guthrie (ispiked)]

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

[Adam Guthrie (ispiked)]

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

[Timeless-bemail (timeless-bemail)]

(From update of attachment 205126)
let's play with this on trunk for a while. if we don't like it, we can arrange to not have the flushes or not have the flushes used for local connections before we release.

[Jesus Cea (jcea)]

The issue is bad enough to a humble block status request.

[Ajschult (ajschult)]

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

[Elmar-ludwig (elmar-ludwig)]

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

[Roc-ocallahan (roc-ocallahan)]

+ if (NS_OK == rv)

These should be NS_SUCCEEDED.

The performance impact of these changes could be huge, even on local displays but worse on remote displays. I think we should measure Trender before they get landed --- ask vlad for help with that. This patch is really only useful if we plan to land it on some 1.8.x branch, since this code will not be used when we ship Gecko 1.9.

[Ajschult (ajschult)]

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

[Dveditz (dveditz)]

No reviewed, trunk-tested, patch, looks like it's missing 1.8.0.2

[Elmar-ludwig (elmar-ludwig)]

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

[Dws (dws)]

Created an attachment (id=213756)
stacktrace after BadDrawable error

I tested the patch of comment #42 but firefox still crashes for me with 1000x1 gif images:

X error code 11 was trapped [BadAlloc (insufficient resources for operation)]. Your page will not display correctly.

Gdk-ERROR **: The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 11197 error_code 9 request_code 72 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.)
aborting...

[Jesus Cea (jcea)]

Anybody working on this?.

Current builds top crashes seems related to this. At least in my system.

Any way I can help?. I don't want to touch Mozilla code };-), but I can reproduce the issue fairly easily and have a lot of experience debugging.

[Timeless-bemail (timeless-bemail)]

it'd be helpful if you built two builds, one w/ the patch, one w/o and then arranged some perf tests. use two clean profiles and see how long basic things take:
1. starting the browser
2. opening a new tab
3. opening a new window
4. loading cnn.com (and other sites, list them...)
5. opening a sheet (if you're using firefox, the customize toolbar widget)
6. opening a dialog (if you're using suite, the open location and find dialogs)
7. loading pages that have lots of graphics
8. loading pages that have a number of plugins
9. loading pages with lots of animations (if you're using suite, the debug menu has some nice samples for animations).

if you can setup your system to use jprof or valgrind in some perf counting mode, that'd be good, since i'm not sure we want to just rely on wall clock watching.

that'd be a good start. there are also official page load test pages, if you can find someone to give you a list of pages that they approximate, that'd be good....

i'm not sure what kind of numbers we need to move this forward, if you can convince roc to specify numbers, that'd be great. but it's probably better for you to just give us raw numbers and see where we go.

[Darin-moz (darin-moz)]

How likely is it that something will land on the trunk with enough bake time to be considered for 1.8.0.3?

[Bzbarsky (bzbarsky)]

My guess is "not at all"; see comment 46.

[Dveditz (dveditz)]

Not blocking 1.8.0-anything without a well-tested trunk landing as a prerequisite

[Dwflo (dwflo)]

Firefoxe exits accessing some web sites. Same behavior with Thunderbird exiting when attempting to read some html messages.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.2) Gecko/20060419 Fedora/1.5.0.2-1.2.fc5 Firefox/1.5.0.2 pango-text
Thunderbird version 1.5 (20060313)

[Ajschult (ajschult)]

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

[Jason Alexandre Ribeiro (jason-ribeiro)]

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

[Adam Guthrie (ispiked)]

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

[Timeless-bemail (timeless-bemail)]

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

[Timeless-bemail (timeless-bemail)]

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

[Darin-moz (darin-moz)]

Not going to block 1.8.1 for this. We'll reconsider if a suitable patch appears.

[Adam Guthrie (ispiked)]

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

[Cbook (cbook)]

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

[Adam Guthrie (ispiked)]

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

[Romaxa (romaxa)]

Same problem on GFX thebes API:
AMD 500MHz, 128RAM, NoSwap.

Current Trunk Cairo Build:
./run-mozilla.sh ./TestGtkEmbed http://www.nih.gov/about/almanac/images/Johnson08091965a.jpg
...................
progress_change_cb cur 655360 max 4463349
progress_change_cb cur 720896 max 4463349
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 1848 error_code 11 request_code 53 minor_code 0)
...................

Current Trunk GTK2 Build:
progress_change_cb cur 4420749 max 4463349
progress_change_cb cur 4463349 max 4463349
./run-mozilla.sh: line 144: 2496 Killed "$prog" ${1+"$@"}

.............

Opera load this image without any problem and there are still a lot of memory...

MemTotal: 127136 kB
MemFree: 3732 kB
Buffers: 1244 kB
Cached: 37028 kB
SwapCached: 0 kB
Active: 92772 kB
Inactive: 20908 kB
HighTotal: 0 kB

Mem: 127136k total, 124460k used, 2676k free, 1820k buffers
Swap: 0k total, 0k used, 0k free, 41076k cached
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2508 romaxa 15 0 74520 54m 9444 S 0.3 43.8 0:09.94 opera
 2062 root 15 0 26628 8636 1680 R 2.3 6.8 1:07.99 Xorg
 2165 romaxa 15 0 36700 8116 2168 S 1.3 6.4 0:16.35 gnome-terminal
 2164 romaxa 15 0 17912 5092 2372 S 0.0 4.0 0:09.35 metacity

[Romaxa (romaxa)]

progress_change_cb cur 720896 max 4463349 - gfx/src/thebes
progress_change_cb cur 4420749 max 4463349 - gfx/src/gtk

According this log current thebes build Thebes build require much more memory for loading this picture.... :(

[Romaxa (romaxa)]

http://www.nih.gov/about/almanac/images/Johnson08091965a.jpg
Normal PC:
Official FF Build thebes:
VmPeak: 197308 kB
VmSize: 120240 kB
VmHWM: 99080 kB
VmRSS: 22772 kB
VmData: 87996 kB - !

Not official FF Build Gtk2:
VmPeak: 120992 kB
VmSize: 62724 kB
VmHWM: 81804 kB
VmRSS: 23376 kB
VmData: 32964 kB - !

[Bzbarsky (bzbarsky)]

Please file a separate bug for the memory usage issue? cc me and dbaron, as well as vlad, pavlov, and roc, and request blocking1.9?

[Roc-ocallahan (roc-ocallahan)]

(From update of attachment 205126)
This patch is obsolete. Probably should file a new bug for this issue on Thebes.

[Mh+mozilla (mh+mozilla)]

Has a new bug been filed for thebes ?

[Matti-mversen (matti-mversen)]

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

[T3st3r (t3st3r)]

FYI: right now there is exists some "joke" in the wild which crashes Firefox users running under X Window system. At least, it works under x64 Linux.

To reproduce:
 Try to load URL: http://lady.mail.ru/img/bg_l.png

Result:
 browser crashes with X window system error.

Output:
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 345764 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.)

[T3st3r (t3st3r)]

Created an attachment (id=376627)
This file causes FF to crash when it runs under X Window system.

[PowerUser (i-am-sergey)]

Binary package hint: firefox

Firefox could be crashed by a remotely-triggered DoS condition causing very unpleasant user experience.

Prerequisuites:
 Firefox 3.0 running under some X Window system. At least x86 and AMD64 Ubuntus are affected.

To reproduce:
 Either load URL like http://lady.mail.ru/img/bg_l.png or open attached file in Firefox

Result:
 Firefox immediately terminated. This allows people to play a bad joke against non-windows OS users causing DoS condition by attempt to load a bad PNG file.

Output:
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 345764 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.)

Notes:
 Upstream haves a bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=210931 and encourage them to fix this bug ASAP.

[PowerUser (i-am-sergey)]

Attached problematic file - just in case if URL fails.

[Jamie Strandboge (jdstrand)]

Verified on Hardy-Karmic. This does not affect Dapper. Marking bug public since the upstream bug is also public.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/bugs/374524

Same info as Comments #73 and #74.

[Micah Gersten (micahg)]

Already reported upstream.

[Mozbugz (mozbugz)]

Attachment 376627 doesn't crash for me with Firefox 3.5.2.

[Hbullen (hbullen)]

Attachment 376627 and http://lady.mail.ru/img/bg_l.png
 dose crash Firefox 3.5.3 for me. However I have to do a "save this link as", or if the png opens in a new tab to a "save this page as". Simplly pasting the URL into the browser doesn't crash firefox.

This is what I get when firefox crashes.

process 21567: type array 97 not a basic type
process 21567: type array 97 not a basic type
process 21567: type invalid 0 not a basic type
process 21567: type invalid 0 not a basic type
process 21567: type struct 114 not a basic type

[Feedback-launchpad (feedback-launchpad)]

John Vivirito added the following comment to Launchpad bug #42683:

This bug is fairly old.
Can anyone confirm this still happens with latest Firefox-3.5 or 3.6?

--
http://launchpad.net/bugs/42683

[Sergey Svishchev (svs)]

NetBSD/i386 4.0, Firefox 3.5.2 here. Attachment 376627 does not crash FF, but it doesn't display either (URL in the address bar changes, but window contents stay the same).

However, FF does crash eventually -- especially during long browsing session. A page with lots of large inline images seems to trigger these crashes (some pages on skyscrapercity.com, for example). I'll try to reproduce this.

[Sergey Svishchev (svs)]

Here's the backtrace from recent crash. I had set a breakpoint at gdk_x_error() and run FF with --sync.

Gdk-ERROR **: 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 199057 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.)
aborting...

Program received signal SIGABRT, Aborted.
0xba25f22f in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xba25f22f in kill () from /usr/lib/libc.so.12
#1 0xba2fb338 in abort () from /usr/lib/libc.so.12
#2 0xba5f5b1d in g_logv () from /usr/pkg/lib/libglib-2.0.so.0
#3 0xba5f5b3b in g_log () from /usr/pkg/lib/libglib-2.0.so.0
#4 0xba8cafa9 in gdk_error_trap_push () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#5 0xba471c73 in _XError () from /usr/pkg/lib/libX11.so.6
#6 0xba4736ee in _XReply () from /usr/pkg/lib/libX11.so.6
#7 0xba46da95 in XSync () from /usr/pkg/lib/libX11.so.6
#8 0xba46dc19 in _XSyncFunction () from /usr/pkg/lib/libX11.so.6
#9 0xba45203b in XCreatePixmap () from /usr/pkg/lib/libX11.so.6
#10 0xba8cbe5a in gdk_pixmap_foreign_new () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#11 0xba89ba8d in gdk_pixmap_new () from /usr/pkg/lib/libgdk-x11-2.0.so.0
#12 0xbb94a74a in gfxPlatformGtk::CreateOffscreenSurface () from /usr/pkg/lib/firefox/libxul.so
#13 0xbb93ab33 in gfxPlatform::OptimizeImage () from /usr/pkg/lib/firefox/libxul.so
#14 0xbb815be6 in non-virtual thunk to nsPrintSession::Release() () from /usr/pkg/lib/firefox/libxul.so
#15 0xbfbfd7a8 in ?? ()
#16 0x08630600 in ?? ()
#17 0x0a175400 in ?? ()
#18 0x00000001 in ?? ()
#19 0x0abdfa9c in ?? ()
#20 0x0a0cc980 in ?? ()
#21 0x0b49ee00 in ?? ()
#22 0x0b49eed0 in ?? ()
#23 0x0b49eecc in ?? ()
#24 0xfffeefb4 in ?? ()
#25 0xbfbfd7e8 in ?? ()
#26 0xbbb9ed20 in ?? () from /usr/pkg/lib/firefox/libxul.so
#27 0x096ff000 in ?? ()
#28 0x0c212b00 in ?? ()
#29 0xbfbfd7d8 in ?? ()
#30 0xbb9224cb in NS_InvokeByIndex_P () from /usr/pkg/lib/firefox/libxul.so
#31 0xbb9224cb in NS_InvokeByIndex_P () from /usr/pkg/lib/firefox/libxul.so
#32 0xbb0b53c9 in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#33 0xbb0c1a7e in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#34 0xbb0c35ac in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#35 0xbb0bd8f1 in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#36 0xbb0b7a5f in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#37 0xbafcb0cc in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#38 0xbb02a3d1 in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#39 0xbafb21c5 in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#40 0xbafb2c0d in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#41 0xbb8dca3f in NS_StringContainerInit2_P () from /usr/pkg/lib/firefox/libxul.so
#42 0xbb8f449c in NS_GetComponentManager_P () from /usr/pkg/lib/firefox/libxul.so
#43 0xbb8...

[Sergey Svishchev (svs)]

If anyone wonders, BadAlloc happened because Xorg process had hit 'data seg size' limit...

[T3st3r (t3st3r)]

Unable to reproduce so far on Firefox 6.0 under Ubuntu 11.10 alpha.

[Feedback-launchpad (feedback-launchpad)]

sam tygier added the following comment to Launchpad bug report 42683:

no crash for me with testcase https://bug210931.bugzilla.mozilla.org/attachment.cgi?id=126641 using official firefox 6 on ubuntu 11.04.

--
http://launchpad.net/bugs/42683

[Bgirard (bgirard)]

Two comments stating that the bug is not reproducible. Can we get an official confirm for this bug?

[Joe-drew (joe-drew)]

I imagine this was fixed way back when we started using Cairo. Please reopen if that's not the case.

[Sergey Svishchev (svs)]

It was, indeed. But lowering 'data seg size' limit exposes other bugs, somewhere in the JS engine.

[PowerUser (i-am-sergey)]

Unable to reproduce this bug on recent Firefox versions.

Mozilla dev's believe this could be fixed due to migration to Cairo engine and at least several people have failed to reproduce this bug as well. Marking it as Fix Released since upstream supposedly released "fixed" version, recent Ubuntu have "fixed" version and I'm unable to imagine better way to close this (obsoleted) bug anyway.