292279 - overly large iframe height or width cause crash.

Status: RESOLVED DUPLICATE of bug 303433

(Core :: Layout, defect)

Description

[Steve Kemp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2)


  Either of the following two examples, contained in a webpage, will cause an
immediate crash of Mozilla or Firefox.

<iframe width="33333333">
<iframe height="33333333">

Reproducible: Always

Steps to Reproduce:
1.  Open browser
2.  Navigate to sample page   http://www.steve.org.uk/firefox/firefox-crash5.html
3.  Browser crashes

Actual Results:  
Browser exits with a segmentation fault on Linux.

Expected Results:  
Displayed a page / Not crashed

Comment 1

[Steve Kemp]

Added blocker on 264944.

Comment 2

[Steve Kemp]

  Confirmed as fixed in the trunk builds of both Mozilla & Firefox.

Comment 3

[Daniel Veditz [:dveditz]]

I couldn't get either example to crash on official 1.0.3 *windows*, and couldn't
load the linked page. I wonder what unknown collection of patches Debian ships
with, or if this is a general Linux-only crash.

Comment 4

[Daniel Veditz [:dveditz]]

I initially thought this might be a dupe of bug 265027 or bug 265084 since those
are fixed on the trunk, but those crashed on windows and I don't crash using 1.0.3

Can someone confirm this on Linux?

Comment 5

[Boris Zbarsky [:bzbarsky]]

The 1.0.3 Mozilla.org tarball release doesn't crash for me on Linux....  Steve,
could you possibly test a Mozilla.org build on your setup?

Comment 6

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

Does this need to be security sensitive?

Comment 7

[Steve Kemp]

(In reply to comment #5)
> The 1.0.3 Mozilla.org tarball release doesn't crash for me on Linux....  Steve,
> could you possibly test a Mozilla.org build on your setup?

  Tested, the mozilla.org build does not crash on the URL given, but does crash
on this:

  http://www.steve.org.uk/firefox/firefox-crash4.html

  Ditto for Mozilla v1.7.7 - crashes on #4, but not on #5.

  My Debian installed packages crash on both, hence my only giving the one URL
in my initial report.

Comment 8

[Steve Kemp]

(In reply to comment #6)
> Does this need to be security sensitive?

  Anybody who believes strongly that it shouldn't be may remove this flag - I
assume 'remote crash == sensitive'.

  Hopefully the comment #7 will lead to others confirming the bug.

Comment 9

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

Most remote crashes are not security sensitive.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Well, I can reproduce the crash with a branch 1.0.3 build on the testcase in
comment 7.

Talkback doesn't come up (though it's installed and enabled, and core _is_
dumped).  My attempt to build a 1.0.3 Firefox debug build failed utterly with:

error: file
'/home/bzbarsky/mozilla/aviary-branch/mozilla/toolkit/locales/en-US/chrome/necko/contents.rdf'
doesn't exist at
/home/bzbarsky/mozilla/aviary-branch/mozilla/config/make-jars.pl line 418.

There's no toolkit/locales/en-US/chrome/necko/contents.rdf file, of course, and
according to bonsai there should be nothing in that directory at all (it's all
in Attic), though I did end up with the other 3 files in that Attic pulled
somehow, reproducibly, when pulling from the AVIARY_1_0_1_20050124_BRANCH tag.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Looks like this got fixed on trunk between 2004-10-11-08 and 2004-10-12-07. 
Probably by widget change caching?  Which means the underlying issue could still
be there....

Comment 12

[Daniel Veditz [:dveditz]]

On the aviary branch the 3 necko locale files are correct:
http://lxr.mozilla.org/aviary101branch/source/toolkit/locales/en-US/chrome/necko/

necko's contents.rdf should come from the toolkit/locales/generic sub-tree:
http://lxr.mozilla.org/aviary101branch/source/toolkit/locales/jar.mn#80

Comment 13

[Boris Zbarsky [:bzbarsky]]

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