Closed Bug 789719 Opened 12 years ago Closed 12 years ago

Frame Poison Crash [@ nsLineBox::IndexOf ] | [@ nsIFrame::GetNextSibling() ] during reflow


(Core :: SVG, defect)

Not set



Tracking Status
firefox16 --- unaffected
firefox17 - verified
firefox18 - verified
firefox19 --- verified
firefox-esr10 --- unaffected
firefox-esr17 --- verified


(Reporter: bc, Assigned: jwatt)




(4 keywords, Whiteboard: [fix in bug 807213][adv-track-main17-])

Crash Data


(2 files, 1 obsolete file)


2. Crash Aurora, Nightly all platforms

Firefox 18.0a1 Crash Report [@ nsLineBox::IndexOf ] 

Maybe dupe of bug 762494

ss since Ted's exploitable rates this as low. iiuc, 0xfffffffff0de801f is poisoned.

Operating system: Windows NT
                  5.1.2600 Service Pack 3
CPU: x86
     GenuineIntel family 6 model 37 stepping 1
     1 CPU

Crash address: 0xfffffffff0de801f

Thread 0 (crashed)
 0  xul.dll!nsIFrame::GetNextSibling() [nsIFrame.h : 1094 + 0xa]
    eip = 0x0238667a   esp = 0x00128f38   ebp = 0x00128f3c   ebx = 0x0cf9b4c0
    esi = 0x00000000   edi = 0x00000000   eax = 0xf0de7fff   ecx = 0xf0de7fff
    edx = 0x00000001   efl = 0x00210286
    Found by: given as instruction pointer in context
 1  xul.dll!nsLineBox::IndexOf(nsIFrame *) [nsLineBox.cpp : 293 + 0x7]
    eip = 0x024c90ec   esp = 0x00128f44   ebp = 0x00128f54
    Found by: call frame info
 2  xul.dll!nsLineBox::Contains(nsIFrame *) [nsLineBox.h : 514 + 0x30]
    eip = 0x0246a69a   esp = 0x00128f5c   ebp = 0x00128f68
    Found by: call frame info
 3  xul.dll!nsBlockInFlowLineIterator::nsBlockInFlowLineIterator(nsBlockFrame *,nsIFrame *,bool *) [nsBlockFrame.cpp : 5258 + 0x12]
    eip = 0x0246efcc   esp = 0x00128f70   ebp = 0x00128fb8
    Found by: call frame info
 4  xul.dll!nsBlockFrame::ChildIsDirty(nsIFrame *) [nsBlockFrame.cpp : 6503 + 0x13]
    eip = 0x02472256   esp = 0x00128fc0   ebp = 0x00129018
    Found by: call frame info
 5  xul.dll!PresShell::FrameNeedsReflow(nsIFrame *,nsIPresShell::IntrinsicDirty,unsigned __int64) [nsPresShell.cpp : 2611 + 0x16]
    eip = 0x02419810   esp = 0x00129020   ebp = 0x0012918c
    Found by: call frame info

Found regression between 20120728145538-20120729152337

I have a local version that reproduces. I'll reduce and attach when its ready.
Attempts to remove the remote resources have failed. If you are interested in the somewhat reduced testcase, let me know but I don't think it would be useful to attach what I have here. Note, during reduction I found that reloading the page helped improve the reproducibility.
Bob, please attach the semi-reduced test, thanks.

I can reproduce in a Linux64 debug asan build, but not Linux64 debug NON-asan
(using the same profile).  It appears the SVG image doesn't even load in the
non-asan build.  Weird.  Maybe your semi-reduced test works better.

> Maybe dupe of bug 762494

Seems likely - bug 762494 comment 1 mentions SVG, which we have on the
stack here.

I think the problem is that PresShell::FrameNeedsReflow is called during
frame tree destruction, and poking about line/frame lists using
nsBlockInFlowLineIterator on an arbitrary frame in the tree doesn't
seem very safe.  Looking at the DeleteLineList call from
nsBlockFrame::DestroyFrom it's clear that the line/frame lists are
in flux here:

While we can make that more robust, I think we should first try making
nsSVGUtils::ScheduleReflowSVG post an async event to request the reflow
of |outerSVGFrame| (using nsWeakFrame).  Would that work?
Component: Layout → SVG
Attached file somewhat reduced testcase (obsolete) —
It seems the patch made one test almost perma-orange:

REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/svg/as-image/img-blobURI-2.html | load failed: timed out waiting for pending paint count to reach zero (after reftest-wait removed and switch to print mode) (waiting for MozAfterPaint)
Keywords: csec-dos
Attached file reduced testcase
Attachment #659967 - Attachment is obsolete: true
I'm working on a fix in bug 792857 that might fix this too.
Assignee: nobody → longsonr
Robert, does that mean you don't think that Mats patch is an appropriate fix for this? (I was just trying to figure out whether it is or isn't.)

I would be curious to know how do we make sure that non-SVG callers of PresShell::FrameNeedsReflow don't call it while frames are being destroyed, if anyone can tell me that.
Mat's patch is not landable due to comment 5. I've taken a different approach. I pass a flag about to say that frames are being destroyed and don't reflow in that case (although I do invalidate). Still fixing/building it, so not sure if it's going to pass all the reftests yet.
(In reply to Robert Longson from comment #10)
> Mat's patch is not landable due to comment 5.

Turning that test permaorange may be a good thing. Turning it from intermittent orange to perma orange can often make it a lot easier to figure out and fix the bug that's causing the intermittent orange.
Patch in bug 792857 fixes this and at least locally, doesn't send comment 5 reftest orange.
Need to check in the crashtest from bug 472782 too I'll add that when I land this.
Assignee: longsonr → nobody
Assignee: nobody → jwatt
Depends on: CVE-2012-5836
The signatures seem to be extremely low volume, just FYI.
(In reply to Robert Kaiser ( from comment #15)
> The signatures seem to be extremely low volume, just FYI.

Given that, and the security rating, no need to track for release.
Fixed by bug 807213 which has now landed for 19, 18 and 17.
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [fix in bug 807213]
Is Firefox 16 affected or is this 17 and higher only?
(In reply to Robert Longson from comment #17)
> Fixed by bug 807213 which has now landed for 19, 18 and 17.

What makes you say that, Robert?

For me, the testcase appears to stop crashing on Mac between:


Which would suggest that DLBI (bug 539356) fixed this for 18 and 19. The pushlog is:
(In reply to Al Billings [:abillings] from comment #18)
> Is Firefox 16 affected or is this 17 and higher only?

Firefox 16 does not crash for me.

Firefox 17 b1 crashes for me, but b2 and later do not. Offhand I'm not sure what fixed this for 17.
(In reply to Jonathan Watt [:jwatt] from comment #19)
> (In reply to Robert Longson from comment #17)
> > Fixed by bug 807213 which has now landed for 19, 18 and 17.
> What makes you say that, Robert?

This was crashing for me when 18 was trunk, it didn't crash when I tested it after your fix landed and I couldn't think of anything else in between that might have fixed it. On top of that the testcase and site both have markers being deleted.
Keywords: testcase, verifyme
Whiteboard: [fix in bug 807213] → [fix in bug 807213][adv-track-main17-]
Group: core-security
Confirmed crash on 2012-09-08, nightly
Confirmed fixed on 2013-01-14, nightly
Confirmed fixed on 2013-01-14, Aurora
Confirmed fixed on 2013-01-14, beta
Confirmed fixed on 17.0.2esr
You need to log in before you can comment on or make changes to this bug.