183309 - Mozilla crashes on startup. - Trunk [@ nsBindingManager::GetXBLDocumentInfo]

Status: VERIFIED FIXED

(Core :: XBL, defect)

Description

[David G King]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

I downloaded todays nightly (Win32 Installer), and the install worked fine
(well, ignoring the 130% downloaded indicator), but when Mozilla started up, it
crashed before it got to the Profile Manager.

I then downloaded the "08" version and had the same problem.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla
2. See Talkback startup for crash.


Actual Results:  
Crash on startup.

Expected Results:  
Mozilla to startup as it did with yesterdays (12/2) nightly build.

See talkback sessions :- TB14674531E, TB14674492Q and TB14674451G.

I first thought this might be Bug #183276, but I'm told I have a different stack.

Comment 1

[David G King]

Hmm, Build ID got Netscape 7.0, as that is what I used to report
this...should've noticed that.

Build ID is 2002120304-TRUNK, and I also tried 2002120308-TRUNK.

Comment 2

[harishd]

Here is the stack for TB14674531E, TB14674492Q and TB14674451G:

nsBindingManager::GetXBLDocumentInfo
[c:/builds/seamonkey/mozilla/content/xbl/src/nsBindingManager.cpp, line 1063]
nsXBLService::LoadBindingDocumentInfo
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 1031]
nsXBLService::GetBindingInternal
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 866]
nsXBLService::GetBindingInternal
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 977]
nsXBLService::BindingReady
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 836]
nsXBLBindingRequest::DocumentLoaded
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 146]
nsXBLStreamListener::Load
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 446]
nsEventListenerManager::HandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1861]
nsDocument::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/base/src/nsDocument.cpp, line 3483]
nsXMLDocument::EndLoad
[c:/builds/seamonkey/mozilla/content/xml/document/src/nsXMLDocument.cpp, line 559]
nsXMLContentSink::DidBuildModel
[c:/builds/seamonkey/mozilla/content/xml/document/src/nsXMLContentSink.cpp, line
412]
nsExpatDriver::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsExpatDriver.cpp, line 973]
nsParser::DidBuildModel
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 1259]
nsParser::ResumeParse [c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp,
line 1805]
nsParser::OnStopRequest
[c:/builds/seamonkey/mozilla/htmlparser/src/nsParser.cpp, line 2434]
nsXBLStreamListener::OnStopRequest
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLService.cpp, line 328]
nsJARChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 609]
nsOnStopRequestEvent::HandleEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp, line 213]
PL_HandleEvent [c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 645] 

Comment 3

[David G King]

Well, line 1063 is in nsBindingManager::GetXBLDocumentInfo which was changed on
12/2/2002 for Bug #177545

Comment 4

[David G King]

Just tried a clean, clean install where I deleted everything out of the "Program
Files/mozilla.org" directory after using the standard Windows Uninstall process.

Still crashed.

Comment 5

[David G King]

Just to make sure it wasn't a problem with an upgrade I did today to ZoneAlarm,
I reinstalled 20021202-TRUNK. It runs fine.

Noticed one very interesting thing, the Win32 Installer had no problem
downloading the 12/02 xpi files, while the 12/04 installer gives "Try Again"
type errors all the time.

Comment 6

[Nicholas Allen]

I ran into this and found that the reason for the crash is that the XUL cache 
is disabled.  Reporter, see if you've got that pref set in your profile.

mDocumentTable has no entries and the return result for the get doesn't appear 
to be checked.  Somebody should find a home for this since Asa doesn't fix bugs.

Alec -- was this exposed by your hashtable changes?

Comment 7

[timeless]

xbl

Comment 8

[David G King]

My XUL cache is disabled. Since this option is in the "Debug" section of the
"Preferances", I've never worried about it.

You seem to suggest that there is a problem that is causing this, so I'm leaving
this bug open. Question: Should this be a Smoketest Blocker bug?

Comment 9

[Boris Zbarsky [:bzbarsky]]

"debug" prefs are prefs that allow you to fuck up the browser completely. 
That's why they're called debug.  Nothing that breaks because a debug pref is
changed from the default is ever a blocker.

That said, does changing that option make the crash go away?

Comment 10

[David G King]

Changing "Disable XUL Cache" to not be checked, fixes the startup problem.

By the way, what are the defaults for the Debug Pref settings?

Comment 11

[David G King]

I answered my own question by creating a new profile and taking a look.

The XUL Cache wasn't the only setting different from the default. I also had to
change a couple of Javascript settings (strict warnings and dump).

Comment 12

[Jay Patel [:jay]]

This is a topcrasher on the MozillaTrunk.  Seems to have started with a huge
spike with 12/3 builds.  I'll attach the latest Talkback data.

Comment 13

[Jay Patel [:jay]]

Attachment: nsBindingManager::GetXBLDocumentInfo crashes on MozillaTrunk

Comment 14

[David G King]

If I remember correctly, from a long time ago, having XUL cache disabled was the
default. Which may explain why we have a lot of crashes. This problem with the
XUL cache has, IMHO, either been exposed by the checkin for Bug #177545, or
caused by it. I suspect the former.

There are two solutions at the moment. The user can turn off the "Disable XUL
Cache" in Edit-Preferences-Debug-Networking, or create a new profile. As using
the XUL cache is now the default, then the first option is better (that is, easier).

Comment 15

[Boris Zbarsky [:bzbarsky]]

"disable XUL cache" has not been the default for at least 2.5 years now (maybe
more, but I have nothing to go on there).

Comment 16

[Jay Patel [:jay]]

summary and keywords somehow got removed!  replacing both.

Comment 17

[Nicholas Allen]

Attachment: Check entry for null

Well, this is the obvious fix.	Spun a build with it and disabling the xul
cache seems to work without crashing again.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 108259 [details] [diff] [review]
Check entry for null

does *aResult get set to nsnull earlier in the function?

if not, please do that.

should you return a failure if entry is null?

Comment 19

[Nicholas Allen]

*aResult is set to nsnull earlier in the function.

Previous versions appear to return NS_OK under all circumstances.  I looked at
all of the callers in lxr and none are checking the return value anyways.

Comment 20

[Alec Flett]

Comment on attachment 108259 [details] [diff] [review]
Check entry for null

oops! Yeah, this looks great.
sr=alecf

make sure to request 1.3a approval as soon as you get an r= - this is an
important fix for 1.3alpha.

Comment 21

[John Morrison]

Running with the XUL Cache disabled has never really been the default, since
"brutal sharing" became functional in December 1999. Really, that pref, the
debug UI for that pref, and any ability to run with the XUL cache should be
removed from the tree. (At minimum, the pref should be renamed to 
'nglayout.debug.use_at_your_own_risk.disable_xul_cache' and the UI removed).

Comment 22

[Brendan Eich [:brendan]]

Comment on attachment 108259 [details] [diff] [review]
Check entry for null

Seems safe enough, but why is entry not found?	If the only reason is that the
XUL cache was disabled by the user, then does the topcrash keyword mean too
many users are often running that way?

/be

Comment 23

[[e-mail]]

I find that the XUL cache makes it difficult to compare builds of Mozilla using
the same profile, they all try and use the latest XUL from the cache :-(

Comment 24

[Asa Dotzler [:asa]]

Comment on attachment 108259 [details] [diff] [review]
Check entry for null

a=asa for checkin to 1.3a

Comment 25

[Nicholas Allen]

Comment on attachment 108259 [details] [diff] [review]
Check entry for null

I don't have CVS commit access so I'll need someone to help run this in. 
r/sr/a are all +'ed

Comment 26

[[e-mail]]

btw, a bug was reported on one of the ngs - with xul cache on,
<?xul-overlay?> only works in chrome.

Comment 27

[Nicholas Allen]

Fix is in.

Thanks to timeless for getting this checked in.

Comment 28

[timeless]

.

Comment 29

[Nicholas Allen]

resolving

Comment 30

[Jay Patel [:jay]]

v.fixed.  this hasn't showed up in Talkback data for a while now.