If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

if a required overlay fails to load, it may trigger ASSERTION: something's on the context stack already: 'mContextStack.Depth() == 0'

NEW
Assigned to

Status

()

Core
XUL
P5
minor
15 years ago
8 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

({assertion})

Trunk
x86
Windows 2000
assertion
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Assignee)

Description

15 years ago
cvs build from sunday afternoon, i don't think i have patches to xul, i do have
one patch to trees and some patches to xbl and i was testing a patch to editor
core by opening editor composer. It turns out that I have some _bad_ patches to
editor's xul, which cause output like this:
Error reading file jar:resource:///chrome/comm.jar!/content/editor/menus.xul
*** Failed to load overlay chrome://editor/content/menus.xul

The reason for that is a silly change:
Index: editor.xul
===================================================================
RCS file: /cvsroot/mozilla/editor/ui/composer/content/editor.xul,v
retrieving revision 1.144
diff -u -r1.144 editor.xul
@@ -35,0 +35,1 @@
+<?xul-overlay href="chrome://editor/content/menus.xul"?>

and the lack of a corresponding packaging change for menus.xul so loading that
url returns an error.

anyway, the console output for the assertion is:
###!!! ASSERTION: something's on the context stack already:
'mContextStack.Depth() == 0', file
i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line 5288
Break: at file i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line
5288

NTDLL! 77f9f9df()
nsDebug::Assertion(const char * 0x04392a54, const char * 0x04392a38, const char
* 0x043929fc, int 5288) line 280 + 13 bytes
nsXULDocument::PrepareToWalk() line 5288 + 47 bytes
nsXULDocument::EndLoad(nsXULDocument * const 0x105aed30) line 1726 + 8 bytes
XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x109b9bf8, int 0)
line 485
nsExpatDriver::DidBuildModel(nsExpatDriver * const 0x1095eeb8, unsigned int 0,
int 1, nsIParser * 0x109b9cc0, nsIContentSink * 0x109b9bf8) line 972 + 23 bytes
nsParser::DidBuildModel(unsigned int 0) line 1283 + 41 bytes
nsParser::ResumeParse(int 1, int 1, int 1) line 1820
nsParser::ContinueParsing() line 1390 + 19 bytes
CSSLoaderImpl::SheetComplete(SheetLoadData * 0x10857a08, int 1) line 1800
CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x109b7af0, SheetLoadData *
0x10857a08, int & 1) line 1733
SheetLoadData::OnStreamComplete(SheetLoadData * const 0x10857a08,
nsIUnicharStreamLoader * 0x109b6e00, nsISupports * 0x00000000, unsigned int 0,
nsIUnicharInputStream * 0x109b7af0) line 1124 + 23 bytes
nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x109b6e04,
nsIRequest * 0x1098e028, nsISupports * 0x00000000, unsigned int 0) line 187
nsJARChannel::OnStopRequest(nsJARChannel * const 0x1098e02c, nsIRequest *
0x109fd874, nsISupports * 0x00000000, unsigned int 0) line 606 + 49 bytes
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x109cb374) line 116
PL_HandleEvent(PLEvent * 0x109cb374) line 663 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01033028) line 593 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00d30782, unsigned int 49306, unsigned int 0,
long 16986152) line 1379 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e13f0f()
nsAppShellService::Run(nsAppShellService * const 0x03e0d608) line 472
main1(int 3, char * * 0x002e44c0, nsISupports * 0x002d6f08) line 1543 + 32 bytes
main(int 3, char * * 0x002e44c0) line 1904 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

and here are selected portions of mContextStack:
-	mContextStack	{...}
|-	mTop	0x109beda8
||-	mPrototype	0x109bb930
|||-	nsXULPrototypeNode	{...}
||||	mType	eType_Element
|||\	mRefCnt	1
|||	mNumChildren	5
|||-	mChildren	0x109d2af8
|||\+		0x0e4cbb70
||\-	mNodeInfo	{...}
|| \-	mRawPtr	0x10990db8
||  |+	[nsNodeInfo]	{...}
||  \-	mInner	{...}
||   |-	mName	0x01071230
||   |\-	[PermanentAtomImpl]	{...}
||   | \-	AtomImpl	{...}
||   |  |+	nsIAtom	{...}
||   |  \-	mString	0x0107123c
||   |   \	[0]	111 "o\0v\0e\0r\0l\0a\0y\0\0\0"
||   \	mNamespaceID	9
||	mNumAttributes	2
||-	mAttributes	0x109bba14
||\-	mNodeInfo	{...}
|| \-	mRawPtr	0x109bba68
||  |+	[nsNodeInfo]	{...}
||  \-	mInner	{...}
||   \-	mName	0x03df5760
||    \-	[PermanentAtomImpl]	{...}
||     \-	AtomImpl	{...}
||      |+	nsIAtom	{...}
||      \-	mString	0x03df576c
||       \	[0]	105 "i\0d\0\0\0"
||+	mPrefix	0x00000000
||	mNamespaceID	0
||+	mElement	0x00000000
||	mIndex	2
|\+	mNext	0x00000000
\	mDepth	1

I think ResumeWalk is buggy.
                else {
                    // We're in the "first ply" of an overlay: the
                    // "hookup" nodes. Create an 'overlay' element so
                    // that we can continue to build content, and
                    // enter a forward reference so we can hook it up
                    // later.
                    rv = CreateOverlayElement(protoele, getter_AddRefs(child));
                    if (NS_FAILED(rv)) return rv;
                }
I'm 99% certain CreateOverlayElement failed, and I believe that when it fails,
we should pop the context before we return.

I'm filing this now because i need to use this browser and that browser for
stuff, i'll attach a patch after i verify that i'm right about the failure.
(Assignee)

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
(Assignee)

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.