369971 - XError: BadAlloc (insufficient resources for operation)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Comment 3

[chris hofmann]

mats, are you still seeing the problem, or have any ideas on how to get jesse reproducing?

Comment 4

[Window Snyder]

Critical security bugs need to have an owner.  If you are not the correct person for this bug, please help us find someone else.  Thanks.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

A minimal testcase would be great.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

It is possible that this was fixed in Bug 374090.

Comment 7

[Mats Palmgren (inactive)]

Preserving TB data from TB29198257X:

Stack Signature	 0x00000000 82ae1aa2
Product ID	FirefoxTrunk
Build ID	2007020611
Trigger Time	2007-02-10 04:42:57.0
Platform	LinuxIntel
Operating System	Linux 2.6.17-10-generic
Module	
URL visited	http://www.apple.com
User Comments	click Store
Since Last Crash	0 sec
Total Uptime	0 sec
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
0x00000000
PresShell::FlushPendingNotifications()  [mozilla/layout/base/nsPresShell.cpp, line 4684]
nsGfxScrollFrameInner::FireScrollPortEvent()  [mozilla/layout/generic/nsGfxScrollFrame.cpp, line 362]
nsThread::ProcessNextEvent()  [mozilla/xpcom/threads/nsThread.cpp, line 483]
NS_ProcessNextEvent_P()  [mozilla/xpcom/build/nsThreadUtils.cpp, line 225]
nsBaseAppShell::Run()  [mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp, line 153]
nsAppStartup::Run()  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 172]
XRE_main()  [mozilla/toolkit/xre/nsAppRunner.cpp, line 2751]
main()  [mozilla/browser/app/nsBrowserApp.cpp, line 62]

Comment 8

[Mats Palmgren (inactive)]

The results are a bit different now.  I can't reproduce the
original crash on Linux, but it still doesn't run for long.
Results:
SeaMonkey and Firefox trunk *debug* builds, Linux:
  XError: BadAlloc (insufficient resources for operation)
  which results in a call to exit().
  see "trunk stack" attachment.

Minefield 20070427 nightly build, Linux:
  does not hit that XError for some reason...
  and no crash

1.8 branch debug build on Linux:
  hangs in some X related operation which never finish
  see "1.8 branch stack" attachment

1 [review].8.0 branch debug build on Linux:
  crashes, but not the original crash (possibly unrelated bug)
  see "1.8.0 branch stack" attachment
  (likely using freed frame or content)

Firefox 2.0.0.4-rc1 on MacOSX 10.4 (Intel):
  silent crash (or exit?) - no Crash Report dialog was opened.

Comment 9

[Mats Palmgren (inactive)]

Attachment: trunk stack

Comment 10

[Mats Palmgren (inactive)]

Attachment: 1.8 branch stack

Comment 11

[Mats Palmgren (inactive)]

Attachment: 1.8.0 branch stack

Comment 12

[Mats Palmgren (inactive)]

I'd still like to keep this bug open for a while to track those XErrors -
the trunk stack data doesn't seem to have obscenely large values so I'm
puzzled why the BadAlloc occurs...

We need to test Windows builds also...

Comment 13

[Mats Palmgren (inactive)]

(In reply to comment #8)
> Firefox 2.0.0.4-rc1 on MacOSX 10.4 (Intel):
>   silent crash (or exit?) - no Crash Report dialog was opened.

Running from a terminal window I get these messages:
  pure virtual method called
  terminate called without an active exception
which usually means we're using freed memory.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Those new stacks look very different. Would it be better to open a new bug for those (and close this one). Is the testcase even the same anymore (I mean the minimal testcase).

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

oh, I didn't notice you already changed the summary.
minimal testcase would be still great.

Comment 16

[Jeff Walden [:Waldo]]

I can't reproduce this in a debug build running inside a Fedora 7 VM.  The original problem doesn't occur, and I don't seem to crash "early"; I have it running at 111000+ right now and haven't crashed.  I get the usual stream of assertions, but this bug WFM.

Comment 17

[Damon Sicore (:damons)]

I've asked qa to verify this one.

Comment 18

[Martijn Wargers (dead)]

It's also worksforme on windows, using a build from 2007-06-20, I had it running till 50000 or so.
With a Linux (Ubuntu on VMWare) I keep hanging at 4732 with a 2007-06-20 build.

Comment 19

[Mats Palmgren (inactive)]

Spawned off bug 385445 which is a 1.8 branch crash on MacOSX.

Comment 20

[Damon Sicore (:damons)]

Ok, so is "hanging at 4732" a security risk on linux?  :)

Looks like this bug is WFM and we should start tracking in bug 385445 ?  If so, can we mark as so?

Comment 21

[Mats Palmgren (inactive)]

The STR now causes a hang in a Firefox trunk debug Linux build, I spawned
that off as bug 387358.  I can still reproduce the XError if I get past
that bug (about 1 in 6).  Removing blocking flag since an XError (or hang)
when running a fuzzer isn't serious enough to block I think.
Did anyone test Windows 1.8/1.8.0 branches?  If there are problems other
than the XError, please file them as separate bugs.

Comment 22

[chris hofmann]

sounds like we should close this bug and open up new ones for any remaining problems.  is that right?

Comment 23

[Mats Palmgren (inactive)]

STR now results in 100% CPU hang, FF trunk 2008011604 Linux.
We should reduce that into a minimal testcase and spawn it off as a
separate bug.  After that hang is fixed we should revisit this bug
and make sure there are no remaining problems, on any platform.

Comment 24

[Daniel Holbert [:dholbert]]

I'm currently seeing this error & crash on http://howtoforge.com, both in trunk and in FF2, using Ubuntu 8.04.

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: testcase

This testcase gives me a crash & this error in FF2 and in Trunk:

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 21373 error_code 11 request_code 53 minor_code 0) 

Occasionally, it doesn't crash, but I still get the error output when I quit.
This testcase uses style info from
 http://howtoforge.com/themes/htf_glass/style.css

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

Can't reproduce on Fedora 7 (32bit and 64bit)
X Window System Version 1.3.0
Build ID: xorg-x11-server 1.3.0.0-16.fc7

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Slightly more minimized version of previous testcase.

For some reason, it seems to matter that style.css is on the howtoforge server.  If I try to use a local copy, or use a copy on my own web server, it doesn't crash or give the BadAlloc error.

Comment 28

[chris hofmann]

no crashes for on the test cases using

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4 

Comment 29

[Daniel Holbert [:dholbert]]

I'm @ home now and I don't see the crash on my home Ubuntu 7.10 box -- maybe it's something specific to Ubuntu 8.04.

(In reply to comment #27)
> For some reason, it seems to matter that style.css is on the howtoforge server.
>  If I try to use a local copy, or use a copy on my own web server, it doesn't
> crash or give the BadAlloc error.

Ah -- this problem was probably due to this relative URL in the stylesheet:
  #header {
    background: url(images/bg_header_bottom_left15.png) bottom left no-repeat;
    ...
   }

I think the crash is related to that PNG, because I never saw it load (or realized it was supposed to be there) when I was testing on my work machine.

Comment 30

[chris hofmann]

I can confirm not seeing the problem on a VM running Ubuntu 7.04 using firefox 3. beta 4

Comment 31

[Daniel Holbert [:dholbert]]

Attachment: PNG that triggers the bug

Here's the PNG that was triggering the bug in the previous testcases I posted.  Simply loading this PNG in Firefox triggers a BadAlloc & crash on my Ubuntu 8.04 machine.

I haven't rebooted since seeing the bug for the first time, so it may be something weird in my current session...

Comment 32

[Daniel Holbert [:dholbert]]

(In reply to comment #31)
> I haven't rebooted since seeing the bug for the first time, so it may be
> something weird in my current session...

Cancel that -- I just rebooted, and I still see the BadAlloc & crash when loading the posted PNG (attachment 310818 [details]).

Firefox: All. (FF2, FF3b4, latest-trunk)
OS: Ubuntu Hardy 8.04
xserver-xorg-core: 2:1.4.1~git20080131-1ubuntu5

Comment 33

[Daniel Holbert [:dholbert]]

If I run Firefox inside of nxserver/nxclient (remote-desktop software from http://nomachine.com/ ) on this Ubuntu 8.04 machine, then I *don't* get a crash.  Instead, it looks like the image shows corrupt memory.

When viewed in FF2, the PNG often shows correctly the first time I load it.  But when I click/move/resize the window, the image turns black, or shows gibberish.

When viewed in FF3 / latest-trunk, the PNG just looks completely white

Comment 34

[Daniel Holbert [:dholbert]]

Attachment: screenshot of gibberish memory in FF2 inside of nxclient

Here's a screenshot of what I'm seeing in FF2 within nxclient.

Comment 35

[Mats Palmgren (inactive)]

Daniel, I can't reproduce the problem with your testcase,
does the branch patch in bug 424333 help?

Comment 36

[Daniel Holbert [:dholbert]]

Can't test the branch patch, as I haven't been able to successfully build branch on Ubuntu 8.04 yet.

I also see this error & crash on FF2 & FF3 at http://tech.yahoo.com/blogs/

Comment 37

[Daniel Holbert [:dholbert]]

I think I'm actually running into Bug 390768 (crash if I open large PNG [XError calls exit on "BadAlloc (insufficient resources for operation)"]), as my earlier crash used a very wide PNG from HowToForge.

I'll direct any further issues I have about this to that bug.

Comment 38

[Daniel Holbert [:dholbert]]

Does this bug page still need to be marked security-sensitive?

I'm asking because two other bugs that trigger the same error / crash as this bug (bug 390768 and bug 424333) are currently *not* marked as security-sensitive.

Or, looking at it from the other direction, should those two other bugs be marked as security-sensitive?

Comment 39

[Mats Palmgren (inactive)]

(In reply to comment #38)
> Does this bug page still need to be marked security-sensitive?

The XError thing is not security-sensitive in itself -- technically
it's not a crash, it's a call to exit() with no security implications
other than sg:dos.  This bug was marked SS because of the original
@FlushPendingNotifications crash which I *think* is WFM now,
at least on trunk and 1.8, it's unclear what the status is for 1.8.0
(comment 8).  A later SS crash spawned bug 385445 for the same STR,
I don't know if that bug still occurs.

> Or, looking at it from the other direction, should those two other bugs be
> marked as security-sensitive?

No, they look like clean XError exit() bugs to me.

Comment 40

[Jesse Ruderman]

Making public based on the last few comments.

Comment 41

[Jesse Ruderman]

dholbert's testcases don't make Firefox trunk crash for me.  (Ubuntu 9.10)

Comment 42

[Daniel Holbert [:dholbert]]

No crash here either, using Ubuntu 9.10 with these builds:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.16pre) Gecko/2009110204 GranParadiso/3.0.16pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091114 Minefield/3.7a1pre

Resolving as WFM.

Comment 44

[Jesse Ruderman]

This might be a dup of bug 424333.  At least one bug mentioning howtoforge was duped there.

Comment 47

[Mats Palmgren (inactive)]

WFM too, on 1.9.0, 1.9.1 and m-c. Testcases and STR.  Kubuntu 9.04 x86-64.