crash if I open large PNG [XError calls exit on "BadAlloc (insufficient resources for operation)"]

RESOLVED DUPLICATE of bug 424333

Status

()

Core
Widget: Gtk
P2
critical
RESOLVED DUPLICATE of bug 424333
10 years ago
7 years ago

People

(Reporter: quintenbernaert, Assigned: vlad)

Tracking

({crash, pp, testcase})

1.9.0 Branch
x86
Linux
crash, pp, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Firefox crashes when I open a large PNG on the url (http://apollo.sese.asu.edu/METRIC_PREVIEW/AS15-M-0081/AS15-M-0081.html).


Reproducible: Always

Steps to Reproduce:
1) Go to http://apollo.sese.asu.edu/METRIC_PREVIEW/AS15-M-0081/AS15-M-0081.html
2) Click "Large PNG, 8.8 m/p (251 MB)"
Actual Results:  
I see the first line/lines of pixels and then Firefox crashes.

Expected Results:  
Load the image.
(Reporter)

Comment 1

10 years ago
Firefox 3 alpha 6 says the image contains errors and it doesn't crash.

Comment 2

10 years ago
Can you get a stacktrace for the crash? http://kb.mozillazine.org/Talkback
Component: General → General
Keywords: crash
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.8 Branch

Comment 3

10 years ago
Created attachment 275211 [details]
stack

XError calls exit in response to an XCreatePixmap error...

Comment 4

10 years ago
We have bugs filed on this, eg bug 348463 and bug 210931.
Status: UNCONFIRMED → NEW
Component: General → Widget: Gtk
Depends on: 210931
Ever confirmed: true
Keywords: pp
QA Contact: general → gtk
Summary: crash if I open large PNG (see url) → crash if I open large PNG [XError calls exit on "BadAlloc (insufficient resources for operation)"]

Comment 5

10 years ago
On a mac with Firefox 2.0.0.9, I get the same behaviour. The two bugs referenced above were reported on Linux with GTK, so I am a bit puzzled. I attach a test-case png which always kills firefox on my mac as well as on Linux when trying to zoom in. A stack trace is also included. The command line spits out this:

/Applications/Firefox.app/Contents/MacOS/run-mozilla.sh: line 424:  9222 Segmentation fault      "$prog" ${1+"$@"}

Is this a bug in Apples rendering? Safari shows the picture nicely...

Comment 6

10 years ago
Created attachment 290214 [details]
Stack trace of Firefox 2.0.0.9 crash on Mac

Comment 7

10 years ago
Sorry, just realized the PNG is too large to show. Try this url:

http://www.sanger.ac.uk/cgi-bin/software/analysis/logomat-m.cgi?pfamid=PF04735

Comment 8

10 years ago
benjamin: file a new bug. this bug is *only* for Gtk. Your crash in apple's code could either be a bug in apple's code, or a bug in some of our mac code, but it needs to be tracked differently.
I see this bug using Ubuntu 8.04, using FF3 and FF2, at these places:
 a) the URL in comment 7
 b) http://www.howtoforge.com
 c) attachment 310818 [details]  (a wide PNG taken from howtoforge.com)
 d) http://tech.yahoo.com/blogs/

I initially posted about this in bug 369971 comment 24 through 37, but I'm directing further info to this bug page, because what I'm seeing is Linux-specific and PNG-specific.

If it matters, my libgtk2.0-0 package is version 2.0-0_2.12.9-2ubuntu1
Daniel, bug 424333 now has a patch for trunk too... does that help?
Nope.  I tested
   attachment 310818 [details]  (evil howtoforge PNG)
along with
   attachment 310964 [details]  (gif that crashes FF, from bug 424333)
and they both still crash (thought the gif takes ~5 seconds)
Oops -- I think I was running the wrong build when I posted comment 11.

I just tested it with the patch correctly applied, and while the patch *does* fix attachment 310964 [details] (gif from bug 424333) on my machine, it doesn't fix attachment 310818 [details] or howtoforge.com or tech.yahoo.com/blogs.
Created attachment 312155 [details]
Stack trace of Trunk crash on Linux (Ubuntu 8.04)

Here's a stack trace I caught in GDB for the linux crash on attachment 310818 [details].

If I continue from this point, I immediately hit the _Xerror call.
I can actually scale the howtoforge image down to 8189px wide and still produce the crash. (but at 8188px wide, we don't crash)

Then, keeping the 8189px width, I can also scale it vertically down to 2px tall and still produce the crash.  (but at 1px, or at 2px by 8188px, we don't crash)

So what's the significance of 8189px?  It's *almost* 2^13:
    2^13 = 8192 = 8189 + 3

So I think we're hitting some byte-count boundary, or something... 

e.g. if we're hypothetically using 4 bits per pixel of width, that puts us at
    8188 * 4 = 32752 = (2^15 - 16) => no crash
    8189 * 4 = 32756 = (2^15 - 12) => crash
so we could be dealing with a signed 16-bit number (i.e. 15 bits of value) which is offset by 16 for some reason, and which is overflowing & causing the crash.
Created attachment 312172 [details]
reduced PNG testcase (crashes firefox on some systems)

Here's a black 2px-high 8189px-wide PNG which crashes both Firefox 2 and trunk builds.  (per my last comment)
For convenience, here's that last testcase as a data-url: http://preview.tinyurl.com/398gxr
Requesting blocking1.9, as this affects trunk (along with branch) and seems fairly serious.
Flags: blocking1.9?
Comment on attachment 312172 [details]
reduced PNG testcase (crashes firefox on some systems)

On my laptop, which is also running Ubuntu 8.04, I only get the crash with the URL from comment 7 -- not with the reduced testcase, the howtoforge.com site, or the tech.yahoo.com/blogs site.
Attachment #312172 - Attachment description: reduced PNG testcase (crashes firefox) → reduced PNG testcase (crashes firefox on some systems)
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Swapping this based on roc's comments -- it's not a regression, but we should fix it at some point.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+

Updated

10 years ago
Duplicate of this bug: 436833

Updated

10 years ago
Duplicate of this bug: 436037

Updated

10 years ago
Version: 1.8 Branch → 1.9.0 Branch

Comment 22

10 years ago
same issue with www.directnet.com (quite critical, it's for Credit Suisse
online banking)
Duplicate of this bug: 448276
In 1.8, it's handled here:

nsresult nsImageGTK::Init(PRInt32 aWidth, PRInt32 aHeight,
                          PRInt32 aDepth, nsMaskRequirements aMaskRequirements)
{

  [snip]

  // X Protocol limits us to image dimensions less than 32767
  // unless we want to go through lots of pain and suffering.
  if (aWidth > SHRT_MAX || aHeight > SHRT_MAX)
    return NS_ERROR_FAILURE;

  [snip]

}
Duplicate of this bug: 448653
Keywords: testcase
The patch in attachment 381814 [details] [diff] [review] in bug 424333 fixes this bug (and duplicates)
for me.
Depends on: 424333
Should this bug be closed then, or is there something still remaining here?
Nothing remaining here besides the issues in bug 424333 as far as I know.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 424333

Updated

7 years ago
You need to log in before you can comment on or make changes to this bug.