This was reported to Mozilla today by iSight Partners. I can confirm that the PoC page (which I'll attach shortly) crashes Firefox 2.0.0.14 on all three platforms. On Mac, I crash with the stack pasted below. Note that address space that we crash on is identical to that mentioned in the advisory. The full report is attached. Process: firefox-bin [28540] Path: /Applications/Firefox 2.app/Contents/MacOS/firefox-bin Identifier: org.mozilla.firefox Version: 2.0.0.14 (2.0.0.14) Code Type: X86 (Native) Parent Process: launchd [1] Date/Time: 2008-06-17 15:03:57.922 -0700 OS Version: Mac OS X 10.5.3 (9D34) Report Version: 6 Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 ??? 0x02020202 0 + 33686018 1 org.mozilla.firefox 0x005f2769 nsBlockFrame::DrainOverflowLines(nsBlockReflowState&) + 959 2 org.mozilla.firefox 0x005f6b48 nsBlockFrame::ComputeFinalSize(nsHTMLReflowState const&, nsBlockReflowState&, nsHTMLReflowMetrics&) + 2498 3 org.mozilla.firefox 0x0042afbc nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&) + 94 4 org.mozilla.firefox 0x0061ecf4 CanvasFrame::GetType() const + 1358 5 org.mozilla.firefox 0x0042afbc nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&) + 94

un-privatizing the PoC for now: it's unnecessary while the bug itself is private and prevents us from including people (via CC:) to help with the bug who aren't already on the security-group. The advisory date was May 10, but this was just received by the security alias when Brandon filed the bug. If we'd received it then we might have been able to get a fix into the all-but-shipped 2.0.0.15 release. Didn't crash in Minefield but hung, possibly because I was out of memory. Need to investigate trunk further. If it is fixed on trunk would be nice to find a "fix" range (and hope it wasn't the reflow-branch landing).

This is without the memory-filling code, which is really annoying if you want to find a regression range for the crash. This still crashes branch, but not trunk.

On trunk the fix range seems to be between 2007-02-06 and 2007-02-07: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+04&maxdate=2007-02-07+07&cvsroot=%2Fcvsroot Somehow fixed by bug 177805, I guess.

bug 177805 is a big change, hopefully there's a simpler band-aid we can take. Damon: please assign to the appropriate person on your team.

I suspect being "fixed" bug bug 177805 means the bug would probably still show up after bug 177805 with a different number in the border attribute.

It might be useful to: * find a different number for border that would still crash the 2007-02-07 build * see if that testcase still crashes trunk + if so, it's useful for testing + if not, find a new fix date Note that bug 177805 changed our internal units from being 20 per point (which, at 96dpi, means 15 per pixel) to being 60 per pixel. If the range of values causing the crash is very specific, you may also need to adjust the body margins and/or the image size.

I'd note that to get attachment 325557 [details] to crash for me on Linux on a 2007-02-06-04-trunk build, I need to set the layout.css.dpi pref to 96 (which is effectively what it will default to for most Windows users and all Mac users, I think).

For what it's worth 35791400 pixels, at 15 twips per pixel (96dpi), is 0x20000058. That's just above nscoord_MAX. I tried a testcase with 8947850 in the 2007-02-07-04-trunk build and that didn't crash for me, though.

In 2007-02-06-04-trunk, 96dpi, on Linux, I see white with values 35791337 and less, see black with 35791338, and crash with 35791339 and higher (I couldn't find an upper limit).

This crashes 2007-02-07-04-trunk on Linux. The crash turned to a hang (still haven't isolated that change), and then the hang turned into loading fine between 2008-03-07-04-trunk and 2008-03-08-04-trunk.

The hang on attachment 325683 [details] started between 2007-07-01-04-trunk and 2007-07-02-04-trunk, but the crash was actually fixed (so there was an interval between when it worked fine) between 2007-06-01-04-trunk and 2007-06-02-04-trunk, which may be the range where we really want to look for a fix.

Actually, that 06-01 to 06-02 crash fix was a fix for crashing on startup, not crashing on this testcase, so it's the wrong range.

Comment on attachment 325683 [details] testcase that crashes after units landing OK, when I said this crashes after the units landing, I must have been testing the wrong build. It doesn't crash for me anymore, so I have nothing useful.

Actually, it does crash after the units landing if I create a fresh profile with the build in question, and the crash went away between 2007-03-11-04-trunk and 2007-03-12-04-trunk.

I'd guess it was probably fixed by attachment 257911 [details] [diff] [review] on bug 372237. Could somebody with a branch tree handy try that?

Yeah, the patch from bug 372237 seems to fix this. I had to alter the patch for branch into this, otherwise it wouldn't compile.

Looks ok to me, but you probably want to ask roc to review the merged version.

Comment on attachment 325743 [details] [diff] [review] branch patch Approved for 1.8.1.15 and 1.8.1.16, a=dveditz for release-drivers Please land on both the MOZILLA_1_8_BRANCH and the GECKO181_20080612_RELBRANCH, and give it both fixed1.8.1.15 and fixed1.8.1.16 keywords.

Checking in nsIFrame.h; /cvsroot/mozilla/layout/generic/nsIFrame.h,v <-- nsIFrame.h new revision: 3.291.6.4; previous revision: 3.291.6.3 done Checked into the MOZILLA_1_8_BRANCH tree. Checking in nsIFrame.h; /cvsroot/mozilla/layout/generic/nsIFrame.h,v <-- nsIFrame.h new revision: 3.291.6.3.28.1; previous revision: 3.291.6.3 done Checked into the GECKO181_20080612_RELBRANCH tree.

Verified crash in Firefox 2.0.0.14. Using build 3 of 2.0.0.15, there is no crash. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15) Gecko/2008062305 Firefox/2.0.0.15

Verified in 2.0.0.16 as well: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/2008070205 Firefox/2.0.0.16.

Comment on attachment 325743 [details] [diff] [review] branch patch a=asac for 1.8.0