210931 - Mozilla should reset the X error handler to trap overallocation failures in gtk/gtk2 libraries [@ nsImageGTK::DrawCompositeTile ]

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Stefan A. Möller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

The website mentioned above uses a malformed javascript which makes Mozilla crash:
w=1024;
h=768;
window.open('','galwin','width='+w+40+',height='+h+40);

No talkback here.

Reproducible: Always

Steps to Reproduce:
See testcase.

Comment 1

[Stefan A. Möller]

Attachment: Testcase

Comment 2

[Bill Mason]

WFM 20030627 PC/WinXP

Comment 3

[Stefan A. Möller]

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

Comment 4

[Olivier Cahagne]

wfm using Firebird 20030626 on WinXP.

Comment 5

[tenthumbs]

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

Comment 6

[tenthumbs]

Attachment: stacktrace

Loading the attachment.

Comment 7

[Mitch]

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.

Comment 8

[Stefan A. Möller]

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.

Comment 9

[Mitch]

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.

Comment 10

[Mitch]

A more descriptive Summary would be

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

Comment 11

[Olivier Cahagne]

does it still happen with latest nightly build ?

Comment 12

[Andrew Schultz]

still crashes with linux trunk 2004011007

Comment 13

[Mitch]

Attachment: 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 ?

Comment 14

[Andrew Schultz]

gtk

Comment 15

[Andrew Schultz]

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

Comment 16

[Mitch]

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.

Comment 17

[Mitch]

Attachment: 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.

Comment 18

[Mitch]

Attachment: New patch for review

unified patch against today's cvs.

Comment 19

[Andrew Schultz]

Comment on attachment 164836 [details] [diff] [review]
New patch for review

Mitch: you can get a diff from CVS with "cvs diff -u filename.cpp"

Comment 20

[Mitch]

Attachment: 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.

Comment 21

[Kenneth Herron]

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

Comment 22

[georgi - hopefully not receiving bugspam]

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

testcase on the web is in bug 267126

Comment 23

[Mitch]

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 ? 

Comment 24

[Christopher Blizzard (:blizzard)]

Comment on attachment 164836 [details] [diff] [review]
New patch for review

I'm not doing reviews at the moment, this should probably go to roc.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 26

[timeless]

Comment on attachment 164860 [details] [diff] [review]
As requested by Andrew.

roc: there's no guarantee that any given size will work, the xserver could just plain not have memory.

Comment 27

[Boris Zbarsky [: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...

Comment 28

[timeless]

Attachment: updated for merge conflicts

Comment 29

[Adam Guthrie]

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

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

can someone address comment #27?

Comment 31

[timeless]

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 :).

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 33

[timeless]

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

Comment 34

[Adam Guthrie]

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

Comment 35

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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

This does not seem to fix bug 319235.

Comment 36

[Adam Guthrie]

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

Comment 37

[Adam Guthrie]

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

Comment 38

[Andrew Schultz]

Attachment: 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.

Comment 39

[Adam Guthrie]

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

Comment 40

[Adam Guthrie]

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

Comment 41

[Adam Guthrie]

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

Comment 42

[timeless]

Comment on attachment 205126 [details] [diff] [review]
include other gdk_pixmap_new callers

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.

Comment 43

[Jesus Cea]

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

Comment 44

[Andrew Schultz]

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

Comment 45

[Elmar Ludwig]

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

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 47

[Andrew Schultz]

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

Comment 48

[Daniel Veditz [:dveditz]]

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

Comment 49

[Elmar Ludwig]

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

Comment 50

[David Schweikert]

Attachment: 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...

Comment 51

[Jesus Cea]

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.

Comment 52

[timeless]

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.

Comment 53

[Darin Fisher]

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

Comment 54

[Boris Zbarsky [:bzbarsky]]

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

Comment 55

[Daniel Veditz [:dveditz]]

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

Comment 56

[David Florence]

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)

Comment 57

[Andrew Schultz]

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

Comment 58

[Jason Ribeiro]

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

Comment 59

[Adam Guthrie]

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

Comment 60

[timeless]

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

Comment 61

[timeless]

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

Comment 62

[Darin Fisher]

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

Comment 63

[Adam Guthrie]

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

Comment 64

[Carsten Book [:Tomcat]]

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

Comment 66

[Oleg Romashin (: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         

Comment 67

[Oleg Romashin (: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.... :(

Comment 68

[Oleg Romashin (: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   - !

Comment 69

[Boris Zbarsky [: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?

Comment 70

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 205126 [details] [diff] [review]
include other gdk_pixmap_new callers

This patch is obsolete. Probably should file a new bug for this issue on Thebes.

Comment 71

[Mike Hommey [:glandium]]

Has a new bug been filed for thebes ?

Comment 73

[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.)

Comment 74

[T3st3r]

Attachment: This file causes FF to crash when it runs under X Window system.

Comment 75

[Micah Gersten]

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

Same info as Comments #73 and #74.

Comment 76

[Karl Tomlinson (:karlt)]

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

Comment 77

[Harry Bullen]

Attachment 376627 [details] 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

Comment 78

[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

Comment 79

[shattered]

NetBSD/i386 4.0, Firefox 3.5.2 here.  Attachment 376627 [details] 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.

Comment 80

[shattered]

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 0xbb8bc5d3 in GetSecurityContext () from /usr/pkg/lib/firefox/libxul.so
#44 0xbb802c8f in JSD_DebuggerOnForUser () from /usr/pkg/lib/firefox/libxul.so
#45 0xbb69f9b0 in DumpJSEval () from /usr/pkg/lib/firefox/libxul.so
#46 0xbaf38fca in XRE_main () from /usr/pkg/lib/firefox/libxul.so
#47 0x0804900a in _rtld_setup ()
#48 0x08048d44 in ___start ()
#49 0x08048ca7 in _start ()

Comment 81

[shattered]

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

Comment 82

[T3st3r]

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

Comment 83

[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

Comment 84

[Benoit Girard (:BenWa)]

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

Comment 85

[Joe Drew (not getting mail)]

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

Comment 86

[shattered]

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