336434 - image height or width attributes crash firefox with some gif images

Status: RESOLVED DUPLICATE of bug 210931

(Core Graveyard :: GFX: Gtk, defect)

Description

[Jason Ribeiro]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060427 Ubuntu/dapper Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060427 Ubuntu/dapper Firefox/1.5.0.2

This bug was originally opened at https://launchpad.net/distros/ubuntu/+source/firefox/+bug/42683


http://splints.customer.netspace.net.au/ditmar800res/winners.html seems to crash mozilla, firefox, and epiphany.  After reading the html, the culprit seems to be line 39:
<img src="winners_files/vertbar.gif" height="39000" width="4">

Here are some steps to verify this is indeed the problem:
$wget --mirror http://splints.customer.netspace.net.au/ditmar800res/winners.html
$firefox splints.customer.netspace.net.au/ditmar800res/winners.html
#firefox crashes
$gvim splints.customer.netspace.net.au/ditmar800res/winners.html
#change line 39, height="39000", to: height="39"
$firefox splints.customer.netspace.net.au/ditmar800res/winners.html
#firefox handles the page fine (doesn't crash on page load)

While looking into it further, I realized that really high values do not crash the browser either.  For example, if you make height=999999, the browsers handle it fine (don't crash on page load).  There seems to be some kind of sweet spot.

Also, this only happens with certain gif images.  I am not sure why.  However, I am including an attachment with the following files:
original_recolored_old.gif --The original image form the url in my comment, but it has been recolored.  Using this WILL crash mozilla, firefox, epiphany

new_created_with_gimp.gif --A new image with the same size as original_recolored_old.gif created in the GIMP.  Using this WILL NOT crash mozilla, firefox, epiphany

firefox_crash.html --An html file to open in your browser.  This uses original_recolored_old.gif by default and will crash your browser.  Change the img src to new_created_with_gimp.gif to see your browser handle the page fine.


Reproducible: Always

Steps to Reproduce:
1. visit http://splints.customer.netspace.net.au/ditmar800res/winners.html

OR

download the attachment, firefox_crash.tar.gz, extract the contents, and open firefox_crash.html

Actual Results:  
Firefox crashes with certain gif files if they are stretched using <img height=> within a certain range.

Expected Results:  
Firefox should either load fine and scale the image or ignore the code and not crash.

This happens on mozilla, epiphany, and firefox.  Here is the relevant terminal output:

$ mozilla http://splints.customer.netspace.net.au/ditmar800res/winners.html
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 2546 error_code 11 request_code 53 minor_code 0)

$ epiphany http://splints.customer.netspace.net.au/ditmar800res/winners.html
The program 'epiphany-browser' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 5120 error_code 11 request_code 53 minor_code 0)

jasonr@luso:~/temp/firefox_crash$ firefox firefox_crash.html
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 3872 error_code 11 request_code 53 minor_code 0)

Comment 1

[Jason Ribeiro]

Attachment: test case for the bug

Comment 2

[Philip Withnall (unavailable)]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060502 Minefield/3.0a1 - Build ID: 0000000000
WFM.
Do you have a Talkback ID or some other kind of complete backtrace? (http://kb.mozillazine.org/Talkback)

Comment 3

[Jason Ribeiro]

Attachment: strace -Ff -tt firefox &> strace-firefox.log

Let me know if anything else would be helpful.  This is an strace of firefox.  I just opened firefox, typed in the url and watched it crash.

Comment 4

[Philip Withnall (unavailable)]

We don't want straces, as they just list the system calls made by Firefox. What we want is a backtrace, as generated by gdb. If you can't use Talkback, please compile Firefox from source (from mozilla.org) with the --enable-debug option and run it.

Comment 5

[Jason Ribeiro]

Attachment: gdb backtrace

attached gdb backtrace of the crash

I used my distributions firefox-dbg package for the symbols.  I am not familiar with gdb so the attached file is the best I could do.  If you need something more specific, please tell me explicitly what I have to do.

This problem occurs with firefox-1.5b2.tar.gz from the firefox download page as well by the way.

Comment 6

[Philip Withnall (unavailable)]

Confirmed, then.

Comment 7

[timeless]

um, normally xerrors spit out "please crash again with --sync". oddly I don't see that in your logs, but please run your gecko critter again w/ --sync and use gdb again to get another stack trace (your stack trace shows symbols are working, which is a good start).

for normal seamonkey, ./seamonkey -g -d gdb --sync should work. i'm not going to think about which gecko you're using, but there's a unix debugging faq that you could read.

Comment 8

[Jason Ribeiro]

Attachment: gdb backtrace after running: firefox -g --sync

I've attached the gdb backtrace after running: firefox -g --sync

timeless, yes you are correct.  The full error did not get copied correctly in my original post.  Here is all of the terminal output I get after runnning firefox and visiting the site:

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 11466 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 9

[timeless]

thanks :)

Comment 10

[Andrew Schultz]

*** This bug has been marked as a duplicate of 210931 ***

Comment 11

[Jason Ribeiro]

(In reply to comment #10)
> 
> *** This bug has been marked as a duplicate of 210931 ***
> 


I looked over bug 210931 before making this post.  The test case provided in bug 210931 does _not_ cause any of my browsers to crash.  Therefore, I think these two bugs are not the same.  I am going to repoen it because of this.  Feel free to leave a comment if you still believe this is a dupe.

Comment 12

[Andrew Schultz]

You crash because you don't have enough memory and gtk bails.  That's bug 210931.

Comment 13

[timeless]

re comment 11, that a testcase in a bug doesn't trigger a problem is not the right way to think about a problem. the question is whether the underlying bug is the same, and since a fix describes the problem, the thing to do is to try the fix. since you've built yourself, why not apply the patch from that bug and see that you don't crash anymore. if you still crash w/ that patch applied, then you can claim that the patch doesn't work and we can see if indeed it isn't the right bug (doubtful) or if there's a bug in the patch (possible).

Comment 14

[Jason Ribeiro]

(In reply to comment #12)
> You crash because you don't have enough memory and gtk bails.  That's bug
> 210931.
> 

You were right, I recompiled with your patch and firefox traps the error without crashing now.  Thanks for the patch.


*** This bug has been marked as a duplicate of 210931 ***