317546 - Crash [@ 00000000()] called from nsMathMLContainerFrame::GetType() line 1162

Status: VERIFIED FIXED

(Core :: MathML, defect)

Comment 1

[Daniel Veditz [:dveditz]]

On the 1.5 branch 'child' in VerifyStyleTree is 0xdddddddd in a debug build which means the value was obtained from a deleted object.

Comment 4

[Daniel Veditz [:dveditz]]

dbaron: status on this one?

Comment 5

[Daniel Veditz [:dveditz]]

Please get this on the trunk and tested

Comment 6

[rbs]

Checked in the trunk.

Comment 7

[Tim Riley [:timr]]

dveditz- Do you still need qawanted?  I assume this is for verifying the fix on the trunk?

bclary- Please provide the qawanted support on this bug.

Comment 8

[Bob Clary [:bc] (inactive)]

no crash in 20060211 debug winxp/trunk. 

Comment 9

[rbs]

Comment on attachment 207474 [details] [diff] [review]
patch updated to the trunk now that bug 309120 is fixed

The 1.8 branch patch needs to come after the branch patch for bug 309120.

Comment 10

[rbs]

I cannot access bug 317544. Can somebody add me there?

Comment 11

[rbs]

Checked in the 1.8 branch.

Comment 12

[Daniel Veditz [:dveditz]]

On the 1.8.0 branch, with the patch from 309120 landed but before landing this one I crash in the comment 0 testcase when the counter hits 971. Adding this patch I start crashing immediately, before the bookmarklet first displays the counter.

Is there some other patch this one depends on?

Comment 13

[rbs]

I think it also needs bug 317544. When I was experimenting in comment 2, they all seemed to interlock together.

Comment 14

[Daniel Veditz [:dveditz]]

On the 1.8.0 branch with bug 309120 and bug 317544 checked in I crash immediately in nsCSSFrameConstructor::WipeContainingBlock with this patch. Since that sounded like bug 329044 I applied the patch from bug 291902 but that just moved things around a little -- I still crash immediately.

The stack on the 1.8.0 branch is now a little different, and happens a little earlier when the counter shows 589:

  dddddddd
  nsLineBox::DeleteLineList(nsPresContext * aPresContext=0x03c15460, nsLineList & aLines={...}) Line 325
  nsBlockFrame::Destroy(nsPresContext * aPresContext=0x03c15460) Line 303
  nsFrameList::DestroyFrames(nsPresContext * aPresContext=0x03c15460) Line 138
  nsContainerFrame::Destroy(nsPresContext * aPresContext=0x03c15460) Line 164
  nsLineBox::DeleteLineList(nsPresContext * aPresContext=0x03c15460, nsLineList & aLines={...}) Line 325
  nsBlockFrame::Destroy(nsPresContext * aPresContext=0x03c15460) Line 303
  nsLineBox::DeleteLineList(nsPresContext * aPresContext=0x03c15460, nsLineList & aLines={...}) Line 325
  nsBlockFrame::Destroy(nsPresContext * aPresContext=0x03c15460) Line 303
  nsBlockFrame::DoRemoveFrame(nsIFrame * aDeletedFrame=0x03e50f9c, int aDestroyFrames=0x00000001) Line 5708
  nsBlockFrame::RemoveFrame(nsIAtom * aListName=0x00000000, nsIFrame * aOldFrame=0x03e50f9c) Line 5500
  nsFrameManager::RemoveFrame(nsIFrame * aParentFrame=0x03f29864, nsIAtom * aListName=0x00000000, nsIFrame * aOldFrame=0x03e50f9c) Line 705
  nsCSSFrameConstructor::ContentRemoved(nsIContent * aContainer=0x03e47cc8, nsIContent * aChild=0x03e01720, int aIndexInContainer=0x00000004, int aInReinsertContent=0x00000000) Line 10028
  PresShell::ContentRemoved(nsIDocument * aDocument=0x03b85428, nsIContent * aContainer=0x03e47cc8, nsIContent * aChild=0x03e01720, int aIndexInContainer=0x00000004) Line 5521
  nsDocument::ContentRemoved(nsIContent * aContainer=0x03e47cc8, nsIContent * aChild=0x03e01720, int aIndexInContainer=0x00000004) Line 2446
  nsHTMLDocument::ContentRemoved(nsIContent * aContainer=0x03e47cc8, nsIContent * aContent=0x03e01720, int aIndexInContainer=0x00000004) Line 1144
  doRemoveChildAt(unsigned int aIndex=0x00000004, int aNotify=0x00000001, nsIContent * aKid=0x03e01720, nsIContent * aParent=0x03e47cc8, nsIDocument * aDocument=0x03b85428, nsAttrAndChildArray & aChildArray={...}) Line 2962
  nsGenericElement::RemoveChildAt(unsigned int aIndex=0x00000004, int aNotify=0x00000001) Line 2840
  nsGenericElement::RemoveChild(nsIDOMNode * aOldChild=0x03e0173c, nsIDOMNode * * aReturn=0x0012e464) Line 3723
  nsHTMLDivElement::RemoveChild(nsIDOMNode * aOldChild=0x03e0173c, nsIDOMNode * * aReturn=0x0012e464) Line 59
  nsGenericElement::doInsertBefore(nsIDOMNode * aNewChild=0x03e0173c, nsIDOMNode * aRefChild=0x03dd89ac, nsIContent * aParent=0x03d96a50, nsIDocument * aDocument=0x03b85428, nsAttrAndChildArray & aChildArray={...}, nsIDOMNode * * aReturn=0x0012e878) Line 3468
  nsGenericElement::InsertBefore(nsIDOMNode * aNewChild=0x03e0173c, nsIDOMNode * aRefChild=0x03dd89ac, nsIDOMNode * * aReturn=0x0012e878) Line 3019
  nsHTMLHtmlElement::InsertBefore(nsIDOMNode * aNewChild=0x03e0173c, nsIDOMNode * aRefChild=0x03dd89ac, nsIDOMNode * * aReturn=0x0012e878) Line 57
  XPTC_InvokeByIndex(nsISupports * that=0x03d96a6c, unsigned int methodIndex=0x0000000f, unsigned int paramCount=0x00000003, nsXPTCVariant * params=0x0012e858) Line 102
  XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD) Line 2152
  XPC_WN_CallMethod(JSContext * cx=0x038fc028, JSObject * obj=0x030b9390, unsigned int argc=0x00000002, long * argv=0x048296c0, long * vp=0x0012eab4) Line 1444
  js_Invoke(JSContext * cx=0x038fc028, unsigned int argc=0x00000002, unsigned int flags=0x00000000) Line 1177
  js_Interpret(JSContext * cx=0x038fc028, unsigned char * pc=0x03f346b9, long * result=0x0012f6ec) Line 3561
  js_Invoke(JSContext * cx=0x038fc028, unsigned int argc=0x00000001, unsigned int flags=0x00000002) Line 1197
  js_InternalInvoke(JSContext * cx=0x038fc028, JSObject * obj=0x0305ebe8, long fval=0x030034a8, unsigned int flags=0x00000000, unsigned int argc=0x00000001, long * argv=0x03f68b08, long * rval=0x0012f928) Line 1274
  JS_CallFunctionValue(JSContext * cx=0x038fc028, JSObject * obj=0x0305ebe8, long fval=0x030034a8, unsigned int argc=0x00000001, long * argv=0x03f68b08, long * rval=0x0012f928) Line 4171
  nsJSContext::CallEventHandler(JSObject * aTarget=0x0305ebe8, JSObject * aHandler=0x030034a8, unsigned int argc=0x00000001, long * argv=0x03f68b08, long * rval=0x0012f928) Line 1411
  nsGlobalWindow::RunTimeout(nsTimeout * aTimeout=0x03ed6b70) Line 6357
  nsGlobalWindow::TimerCallback(nsITimer * aTimer=0x03ed6338, void * aClosure=0x03ed6b70) Line 6723
  nsTimerImpl::Fire() Line 394
  nsTimerManager::FireNextIdleTimer() Line 628
  nsAppShell::Run() Line 141
  nsAppStartup::Run() Line 150
  XRE_main(int argc=0x00000003, char * * argv=0x00a179a8, const nsXREAppData * aAppData=0x00430090) Line 2351
  main(int argc=0x00000003, char * * argv=0x00a179a8) Line 61
  mainCRTStartup() Line 398

Comment 15

[Daniel Veditz [:dveditz]]

Although with the patch it crashes immediately, with the patch in bug 291902 it's a safe null deref crash. We should probably go with it for the branch. (aCommand passed to IncrementalReflow::AddCommand contains a null frame, asserts "reflow command with no target: 'frame != nsnull'")

Comment 16

[rbs]

> IncrementalReflow::AddCommand contains a null frame

That was bug 286122 (it's attachment 200712 [details] [diff] [review] had earlier been checked in). Perhaps it should go on the branch too?

Comment 17

[Tim Riley [:timr]]

It sounds like we still want this for 1.8.0.2.  Who is going to check that this works for 1.8.0.2 and request approval?  We need this ASAP as it is a blocker for this release.

Comment 18

[rbs]

BTW, I am in need of help to get my build environment back. Am I the only one having issues with the newish VC8 (express) build requirements? https://bugzilla.mozilla.org/show_bug.cgi?id=329209#c9

Comment 19

[Tim Riley [:timr]]

Comment on attachment 207474 [details] [diff] [review]
patch updated to the trunk now that bug 309120 is fixed

a=timr after discussion with dveditz

Comment 20

[Daniel Veditz [:dveditz]]

(In reply to comment #16)
> > IncrementalReflow::AddCommand contains a null frame
> That was bug 286122 [...] Perhaps it should go on the branch too?

If I add that patch I'm back to the potentially exploitable stack in comment 14. I'm going to skip that one for 1.8.0 and go for the safe crash.

On 1.8.1 we probably want it, plus a real fix for the stack in comment 14.

Comment 21

[Daniel Veditz [:dveditz]]

Got a ton of "dangling frame without a content node" assertions before crashing, if that helps point the way.

Comment 23

[Bob Clary [:bc] (inactive)]

fwiw, today's trunk winxp crashes on exit with 

+		this	0x04332354 {mImpl=0xdddddddd }	const nsVoidArray * const

class NS_COM_GLUE nsVoidArray {
public:
  nsVoidArray();
  nsVoidArray(PRInt32 aCount);  // initial count of aCount elements set to nsnull
  ~nsVoidArray();

  nsVoidArray& operator=(const nsVoidArray& other);

  inline PRInt32 Count() const {
=>    return mImpl ? mImpl->mCount : 0;
  }

>	xpcom_core.dll!nsVoidArray::Count()  Line 62 + 0xd bytes	C++
 	firefox.exe!nsGlyphTableList::AdditionalCount()  Line 702	C++
 	firefox.exe!nsGlyphTableList::Finalize()  Line 809 + 0x8 bytes	C++
 	firefox.exe!nsGlyphTableList::Observe(nsISupports * aSubject=0x0214d7e4, const char * aTopic=0x0034c43c, const unsigned short * someData=0x00000000)  Line 775	C++
 	xpcom_core.dll!nsObserverList::Notify(nsIObserver * aObserver=0x04332340, void * aClosure=0x0012fba8)  Line 138	C++
 	xpcom_core.dll!nsObserverList::EnumerateObservers(void (nsIObserver *, void *)* aFunc=0x002adc10, void * aClosure=0x0012fba8)  Line 112 + 0x1e bytes	C++
 	xpcom_core.dll!nsObserverList::NotifyObservers(nsISupports * aSubject=0x0214d7e4, const char * aTopic=0x0034c43c, const unsigned short * someData=0x00000000)  Line 131	C++
 	xpcom_core.dll!nsObserverService::NotifyObservers(nsISupports * aSubject=0x0214d7e4, const char * aTopic=0x0034c43c, const unsigned short * someData=0x00000000)  Line 177	C++
 	xpcom_core.dll!NS_ShutdownXPCOM_P(nsIServiceManager * servMgr=0x0214d7e4)  Line 698	C++
 	firefox.exe!ScopedXPCOMStartup::~ScopedXPCOMStartup()  Line 556 + 0xc bytes	C++
 	firefox.exe!XRE_main(int argc=4, char * * argv=0x02147740, const nsXREAppData * aAppData=0x0139cf20)  Line 2403	C++
 	firefox.exe!main(int argc=4, char * * argv=0x02147740)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes	

file a new bug?

Comment 24

[Daniel Veditz [:dveditz]]

Fix checked into the 1.8.0 branch

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, comment 23 sounds like a separate bug.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Are we confident we haven't made things worse by taking some of these related patches but not others?

Comment 27

[Bob Clary [:bc] (inactive)]

different null ref crash for 1.8.0.2/20060308/winxp