The default bug view has changed. See this FAQ.

Crash [@gklayout!nsIFrame::GetStateBits(void)]

VERIFIED FIXED in mozilla1.9beta1

Status

()

Core
General
--
critical
VERIFIED FIXED
10 years ago
3 years ago

People

(Reporter: Paul Nickerson, Assigned: mats)

Tracking

(4 keywords)

1.8 Branch
mozilla1.9beta1
crash, testcase, verified1.8.0.14, verified1.8.1.8
Points:
---
Bug Flags:
blocking1.8.1.8 +
blocking1.8.0.14 +
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?] using freed frame, crash signature)

Attachments

(4 attachments, 4 obsolete attachments)

(Reporter)

Description

10 years ago
This bug has been automatically processed, reduced, and uploaded by Paul's Automated Pen-Tester alpha. It still may require more work.

Firefox version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070812 BonEcho/2.0.0.6

Details:
eax=dddddddd ebx=7ffde000 ecx=dddddddd edx=dddddddd esi=00a078d8 edi=00011970
eip=0197f53a esp=0012df74 ebp=0012df78 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
*** WARNING: Unable to verify checksum for C:\mozilla\mozilla\firefox-debug\dist\bin\components\gklayout.dll
gklayout!nsIFrame::GetStateBits+0xa:
0197f53a 8b4024          mov     eax,dword ptr [eax+24h] ds:0023:ddddde01=????????


Stack trace:
gklayout!nsIFrame::GetStateBits(void)
gklayout!IsFrameSpecial(

                        class nsIFrame * aFrame = 0xdddddddd)
gklayout!GetIBContainingBlockFor(

                        class nsIFrame * aFrame = 0x03c9fa60)
gklayout!nsCSSFrameConstructor::ReframeContainingBlock(

                        class nsIFrame * aFrame = 0x03c9fa60)
gklayout!nsCSSFrameConstructor::ContentRemoved(

                        class nsIContent * aContainer = 0x03c56a20, 

                        class nsIContent * aChild = 0x03c57148, 

                        int aIndexInContainer = 0, 

                        int aInReinsertContent = 0)
gklayout!nsCSSFrameConstructor::RecreateFramesForContent(

                        class nsIContent * aContent = 0x03c57148)
gklayout!nsCSSFrameConstructor::ProcessRestyledFrames(

                        class nsStyleChangeList * aChangeList = 0x0012e284)
gklayout!nsIPresShell::ReconstructStyleDataInternal(void)
gklayout!nsIPresShell::ReconstructStyleData(void)
gklayout!PresShell::EndUpdate(

                        class nsIDocument * aDocument = 0x033978c8, 

                        unsigned int aUpdateType = 2)
gklayout!nsDocument::EndUpdate(

                        unsigned int aUpdateType = 2)
gklayout!nsStyleLinkElement::UpdateStyleSheet(

                        class nsIDocument * aOldDocument = 0x033978c8, 

                        class nsICSSLoaderObserver * aObserver = 0x00000000)
gklayout!nsHTMLStyleElement::UnbindFromTree(

                        int aDeep = 1, 

                        int aNullParent = 1)
gklayout!doRemoveChildAt(

                        unsigned int aIndex = 4, 

                        int aNotify = 1, 

                        class nsIContent * aKid = 0x03cb7848, 

                        class nsIContent * aParent = 0x035cadc8, 

                        class nsIDocument * aDocument = 0x033978c8, 

                        class nsAttrAndChildArray * aChildArray = 0x035cade0)
gklayout!nsGenericElement::RemoveChildAt(

                        unsigned int aIndex = 4, 

                        int aNotify = 1)
gklayout!nsGenericElement::RemoveChild(

                        class nsIDOMNode * aOldChild = 0x03cb7864, 

                        class nsIDOMNode ** aReturn = 0x0012ea68)
gklayout!nsHTMLHeadElement::RemoveChild(

                        class nsIDOMNode * aOldChild = 0x03cb7864, 

                        class nsIDOMNode ** aReturn = 0x0012ea68)
xpcom_core!XPTC_InvokeByIndex(

                        class nsISupports * that = 0x035cade4, 

                        unsigned int methodIndex = 0x11, 

                        unsigned int paramCount = 2, 

                        struct nsXPTCVariant * params = 0x0012ea58)
xpc3250!XPCWrappedNative::CallMethod(

                        class XPCCallContext * ccx = 0x0012ebd4, 

                        XPCWrappedNative::CallMode mode = CALL_METHOD (0))
xpc3250!XPC_WN_CallMethod(

                        struct JSContext * cx = 0x032f2e60, 

                        struct JSObject * obj = 0x02d246b8, 

                        unsigned int argc = 1, 

                        long * argv = 0x03ab64b4, 

                        long * vp = 0x0012ed34)


A hash of the backtrace has been used to distinguish this from other bugs already reported by the tester. However, the automated pen-tester is still in development and this may not be the case. Also, I haven't added stack hashes to bugs that were not uploaded by the tester, so this bug may very well exist on bugzilla already.
(Reporter)

Comment 1

10 years ago
[STACKHASH:6EC9645E4CF4BDF1C13A75AA31BF2BFD]
(Reporter)

Comment 2

10 years ago
Well, on the plus side, the pen-tester worked (almost) the whole way through. Still gotta work on the attachment uploader. On the down side, it reported the same bug as last time :P
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 392123
(Reporter)

Comment 3

10 years ago
Actually, looking back at this thing, I changed my mind about the duplicate.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 4

10 years ago
Created attachment 276746 [details]
Manually uploaded testcase
(Assignee)

Comment 5

10 years ago
Created attachment 276757 [details]
Stack (prior to crash)
(Assignee)

Comment 6

10 years ago
NotifyListBoxBody() calls listBoxObject->GetListBoxBody() in an attempt
to get the frame, but that flushes frames so end up with a recursive call
to RecreateFramesForContent()... see attached stack.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/base/nsCSSFrameConstructor.cpp&rev=1.1110.6.81&root=/cvsroot&mark=9220#9196
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/xul/base/src/nsBoxObject.cpp&rev=1.50.10.6&root=/cvsroot&mark=170#164
Assignee: nobody → mats.palmgren
Status: REOPENED → NEW
Flags: blocking1.8.1.7?
Flags: blocking1.8.0.14?
Keywords: testcase
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:critical?] using freed frame
(Assignee)

Comment 7

10 years ago
Created attachment 276758 [details] [diff] [review]
Wallpaper

This is a somewhat low-risk wallpaper we could take on branches unless
someone has a better idea.
(Assignee)

Updated

10 years ago
Version: unspecified → 1.8 Branch
We need a version of GetListBoxBody that doesn't flush frames to use here.  The weakframe approach is sorta-maybe ok, but I'm not sure I would trust it to insure against all possible ways to try to damage the frame tree....
Flags: blocking1.9?
(Assignee)

Comment 9

10 years ago
Created attachment 276921 [details] [diff] [review]
Branch patch
Attachment #276758 - Attachment is obsolete: true
Attachment #276921 - Flags: superreview?(bzbarsky)
Attachment #276921 - Flags: review?(bzbarsky)
(Assignee)

Comment 10

10 years ago
It looks to me like this could also crash on trunk since GetListBoxBody()
leads to a Flush_Frames there too.  But the testcase doesn't trigger the
RecreateFramesForContent() call on trunk so we don't reach
NotifyListBoxBody().  I'm guessing a slightly different testcase would
crash on trunk though.
(Assignee)

Updated

10 years ago
Attachment #276921 - Attachment is obsolete: true
Attachment #276921 - Flags: superreview?(bzbarsky)
Attachment #276921 - Flags: review?(bzbarsky)
(Assignee)

Comment 11

10 years ago
Created attachment 276930 [details] [diff] [review]
Branch patch
Attachment #276930 - Flags: superreview?(bzbarsky)
Attachment #276930 - Flags: review?(bzbarsky)
Comment on attachment 276930 [details] [diff] [review]
Branch patch

We're not changing interfaces on branch.  Please add a new interface with the new method on it instead, and QI as needed.  See the various MOZILLA_1_8_BRANCH stuff on the branch.

On trunk this approach looks good, though.
Attachment #276930 - Flags: superreview?(bzbarsky)
Attachment #276930 - Flags: superreview-
Attachment #276930 - Flags: review?(bzbarsky)
Attachment #276930 - Flags: review-
(Assignee)

Comment 13

10 years ago
> We're not changing interfaces on branch.

Ok, I somehow thought we could change the "private" ones, i.e. those
with "nsPI" in the name...
(Assignee)

Comment 14

10 years ago
Created attachment 276967 [details] [diff] [review]
Branch patch, rev. 3
Attachment #276930 - Attachment is obsolete: true
Attachment #276967 - Flags: superreview?(bzbarsky)
Attachment #276967 - Flags: review?(bzbarsky)
(Assignee)

Comment 15

10 years ago
Created attachment 276969 [details] [diff] [review]
Branch patch, rev. 4

... shouldn't change IID for nsPIListBoxObject of course...
Attachment #276967 - Attachment is obsolete: true
Attachment #276969 - Flags: superreview?(bzbarsky)
Attachment #276969 - Flags: review?(bzbarsky)
Attachment #276967 - Flags: superreview?(bzbarsky)
Attachment #276967 - Flags: review?(bzbarsky)
Comment on attachment 276969 [details] [diff] [review]
Branch patch, rev. 4

Looks good.  I agree that we should do this on trunk too.
Attachment #276969 - Flags: superreview?(bzbarsky)
Attachment #276969 - Flags: superreview+
Attachment #276969 - Flags: review?(bzbarsky)
Attachment #276969 - Flags: review+
Flags: blocking1.8.1.7?
Flags: blocking1.8.1.7+
Flags: blocking1.8.0.14?
Flags: blocking1.8.0.14+
Comment on attachment 276969 [details] [diff] [review]
Branch patch, rev. 4

Is this attachment ready for a branch approval request? If this is an appropriate fix for the trunk could we land it there first for some sanity checking?
Mats: is this fix going to make the 1.8.1.8 code freeze (Oct 3)?
(Assignee)

Comment 19

10 years ago
Comment on attachment 276969 [details] [diff] [review]
Branch patch, rev. 4

It's ready for both branches.
Attachment #276969 - Flags: approval1.8.1.8?
Attachment #276969 - Flags: approval1.8.0.14?
(Assignee)

Comment 20

10 years ago
Created attachment 283297 [details] [diff] [review]
Trunk patch, rev. 1
Attachment #283297 - Flags: superreview?(bzbarsky)
Attachment #283297 - Flags: review?(bzbarsky)
Comment on attachment 283297 [details] [diff] [review]
Trunk patch, rev. 1

r+sr=bzbarsky
Attachment #283297 - Flags: superreview?(bzbarsky)
Attachment #283297 - Flags: superreview+
Attachment #283297 - Flags: review?(bzbarsky)
Attachment #283297 - Flags: review+
(Assignee)

Comment 22

10 years ago
Comment on attachment 283297 [details] [diff] [review]
Trunk patch, rev. 1

Low-risk crash fix, if I can get this landed *now* it will give some "baking value" for the branch fix as well.
Attachment #283297 - Flags: approval1.9?
Comment on attachment 276969 [details] [diff] [review]
Branch patch, rev. 4

approved for 1.8.1.8 and 1.8.0.14, a=dveditz
Attachment #276969 - Flags: approval1.8.1.8?
Attachment #276969 - Flags: approval1.8.1.8+
Attachment #276969 - Flags: approval1.8.0.14?
Attachment #276969 - Flags: approval1.8.0.14+
(Assignee)

Comment 24

10 years ago
MOZILLA_1_8_BRANCH
mozilla/layout/base/nsCSSFrameConstructor.cpp 	1.1110.6.90
mozilla/layout/xul/base/src/nsListBoxObject.cpp 	1.16.12.3
mozilla/layout/xul/base/src/nsPIListBoxObject.h 	1.1.2.3

MOZILLA_1_8_0_BRANCH
mozilla/layout/base/nsCSSFrameConstructor.cpp 	1.1110.6.12.2.65
mozilla/layout/xul/base/src/nsListBoxObject.cpp 	1.16.16.3
mozilla/layout/xul/base/src/nsPIListBoxObject.h 	1.1.4.3
Keywords: fixed1.8.0.14, fixed1.8.1.8

Updated

10 years ago
Attachment #283297 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 25

10 years ago
trunk:
mozilla/layout/base/nsCSSFrameConstructor.cpp 	1.1407
mozilla/layout/xul/base/src/nsListBoxObject.cpp 	1.25
mozilla/layout/xul/base/src/nsPIListBoxObject.h 	1.3 

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 10 years ago10 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9
verified fixed on trunk with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007101204 Minefield/3.0a9pre ID:2007101204

also verified fixed 1.8.1.8 using  Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8

No crash on testcase - adding verified keyword
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.8 → verified1.8.1.8
Group: security
Verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.14pre) Gecko/20071210 Firefox/1.5.0.13pre. It still crashes in 1.5.0.12 Firefox but not in the current branch build above.

Marked as "Fixed" since this is a branch only bug.
Keywords: fixed1.8.0.14 → verified1.8.0.14
Duplicate of this bug: 392123
Crash Signature: [@gklayout!nsIFrame::GetStateBits(void)]
(Assignee)

Comment 31

3 years ago
Created attachment 8510623 [details] [diff] [review]
REINTRODUCE-BUG-392285

I tried reintroducing the bug to see if the attached test would crash
but it didn't.
(Assignee)

Updated

3 years ago
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.