348075 - Assertions 'mState != eInEpilog' in nsXULContentSink.cpp on startup

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Pam Greene]

Updated my tree and rebuilt; now getting hundreds of these assertions on startup:

###!!! ASSERTION: tag in XUL doc epilog: 'mState != eInEpilog', file /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 721
Break: at file /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 721

Apologies if this is assigned to the wrong component.

Comment 1

[Jesse Ruderman]

I've been seeing these too, especially when switching from a nightly to my debug build.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is this Mac-only?  I don't see this on Linux....

If so, what's the document URI in question?

Comment 3

[Pam Greene]

It may well be Mac-only.  I've only noticed it on startup, so the URI it's loading is http://www.mozilla.org/projects/bonecho/index-2.0b1.html.  And -- of course -- I can't reproduce it right now.  (Note that this is my local build, not a nightly.)  I'll keep trying.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I meant the URI of the mDocument of the nsXULContentSink -- the XUL file we're parsing when we hit the assert.  If this is mac-only, the problem could be bogus #ifdefs somewhere, say.

Comment 5

[Pam Greene]

I've now been able to reproduce the problem a couple of times, but I haven't tracked down what combination of conditions makes it happen.  I have, however, gotten an additional line of context for the assertion, in case it's any help:

WARNING: NS_ENSURE_TRUE(mimeHdrParser) failed, file /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 1180
###!!! ASSERTION: tag in XUL doc epilog: 'mState != eInEpilog', file /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 721
Break: at file /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp, line 721

...followed by hundreds more of that last assertion.  I'll keep working on reproducing the problem.

Comment 6

[Mike Schroepfer]

--> Pam to help isolate the cause and then we can reassign.

Comment 7

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

(In reply to comment #5)
> WARNING: NS_ENSURE_TRUE(mimeHdrParser) failed, file
> /Users/pamg/Development/mozilla/branch_source/mozilla/content/xul/document/src/nsXULContentSink.cpp,
> line 1180

Might the unexpected failure here explain how things got into an inconsistent state?

Comment 8

[Boris Zbarsky [:bzbarsky]]

That could do it.  That would make us bail out without pushing things on the tag stack and then if we pop things normally we'll run into something very much like this problem.  Note that nsExpatDriver::HandleStartElement ignores the return value from mSink->HandleStartElement() (which would be an error in this case); I think it should abort the parse instead.

All that said, I wonder why we're failing to get that service.  That's the thing to really debug...

Comment 9

[Pam Greene]

Setting qawanted because although I'm still seeing this fairly often, I can't narrow down the conditions that cause it, nor get it to reproduce in a debugger.

Comment 10

[Mike Schroepfer]

Pulling off the 1.8.1 blocker list - please re-nom if we get any actionable information.

Comment 11

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

(In reply to comment #8)
> All that said, I wonder why we're failing to get that service.  That's the
> thing to really debug...

It could happen if the initialization of the module in which the service lives is currently on the stack when the getService call is made.

Comment 12

[Daniel Veditz [:dveditz]]

Not making progress, moving to the branch-wanted list instead of the blocker list.

Comment 13

[Jesse Ruderman]

WFM on Mac trunk.

Comment 14

[Pam Greene]

(In reply to comment #6)
> --> Pam to help isolate the cause and then we can reassign.

I haven't been able to reproduce it recently either.  Going to mark it WFM for now, reopen if it pops up again.