391311 - Topcrash: [@ nsChromeRegistry::CheckForNewChrome] during startup

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P2)

Description

[Mats Palmgren (inactive)]

Topcrash: [@ nsChromeRegistry::CheckForNewChrome] during startup.
Currently #13 with 835 crashes the past month.
Seems to be Windows only.

http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=contains&product=Firefox&signature=nsChromeRegistry%3A%3ACheckForNewChrome()&range_value=1

nsChromeRegistry::CheckForNewChrome()
nsChromeRegistry::Init()
nsChromeRegistryConstructor
nsGenericFactory::CreateInstance(nsISupports*, nsID const&, void**)
nsComponentManagerImpl::CreateInstanceByContractID
nsComponentManagerImpl::GetServiceByContractID
CallGetService(char const*, nsID const&, void**)
nsGetServiceByContractID::operator()(nsID const&, void**)
nsCOMPtr_base::assign_from_gs_contractid
nsCOMPtr<nsIToolkitChromeRegistry>::nsCOMPtr<nsIToolkitChromeRegistry>
ScopedXPCOMStartup::SetWindowCreator(nsINativeAppSupport*)
XRE_main
main
WinMain
__tmainCRTStartup
BaseProcessStart

Comment 1

[Benjamin Smedberg]

The crash appears to have mostly gone away (I don't know why). Please re-nominate if the stats come back.

Comment 2

[Nickolay_Ponomarev]

Unless I'm misreading something, this is #9 topcrash for beta 1 with 1004 reports (and this is not win-only):
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b1

Comment 3

[Benjamin Smedberg]

The crashes are supposedly blaming http://mxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#1128, which means that the QI at http://mxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#1124 failed... it shouldn't ever fail (hence the assertion)... I could add a null-check, but that would probably just shift it from a crash to weird unexpected behavior.

I'd love to find somebody who can reproduce this.

Comment 4

[Samuel Sidler (old account; do not CC)]

It's still, currently, the number 10 topcrash for Firefox 3 Beta 3.

Comment 5

[chris hofmann]

its moving up in the rankings.  now at #7 for beta3
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b3

Comment 6

[Dave Townsend [:mossop]]

Well it may be at 7 there, but in the top crashers for currently nightlies it doesn't feature at all.

http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b4pre

Maybe we have less users on 30.b4pre, but we do seem to have a similar number of crashes across the board there.

Comment 7

[chris hofmann]

so there could be 3 or more things going on given the way we have seen crash patterns for obscure bugs in the past.

1)

looking at the trending on http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b3&range_value=2&signature=nsChromeRegistry%3A%3ACheckForNewChrome%28%29
it might be following the number of people downloading and upgrading from firefox 2 to try out the fx3 beta, and it could be a migration bug.  those upgrading and running from trunk nightlies are unlikely to see these kind of fx2->fx3 migration bugs.   we will need more data to confirm a theory like that, like watching for this in beta 4 as well.  

2)

beta3 has significantly more users than trunk nightlies.  maybe as much as 10x or more, so it could also just take that kind of volume use to surface the bug.

3)

or, it might be fixed....

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Please renom if the numbers come back after beta 4

Comment 9

[chris hofmann]

b4pre and b4 already showing a few reports. 

there are a few comments that we can now dig out of the b3 data. definitely looks like a migration bug that inhibits people from geting firefox 3 up and running.   we will need some help in translating some of the feedback...

these came on windows NT5.1.2600  SP2

De acordo com informação já enviada houve sobreposição feita por um familiar meu que instalou firefox 2.0.0.12 e o computador estava firefox 3 beta, o qual desejo manter como estava.

UM familiar instalou o firefox 2 e eu já tinha firefox 3 beta ao qual quero continuar.Entretanto já desinstalei firefox 2. Gostaria tambem recuperar separadores e janelas que existiam no beta. Cumprimentos

can not get browser to start, rebooting did not fix problem

Unable to start Firefox 3b3

Tried to change from IE to Firefox 3 Beta 3


Já fiz restauro mas continua com problema acaso poderão recuperar todas janelas e separadores ? Tenho uma certa urgência. Cumprimentos

Comment 10

[/\/\arcio Galli]

Just some translation to the 2 above pt-BR paragraphs: 
===

De acordo com informação já enviada houve sobreposição feita por um
familiar meu que instalou firefox 2.0.0.12 e o computador estava firefox 3
beta, o qual desejo manter como estava. 

--> 

Based on information previously sent, my relative installed Firefox 2.0.0.12 in my computer where I had Firefox 3 beta, which is the one I want it to have back. 

============

UM familiar instalou o firefox 2 e eu já tinha firefox 3 beta ao qual quero
continuar.Entretanto já desinstalei firefox 2. Gostaria tambem recuperar
separadores e janelas que existiam no beta. Cumprimentos

---> 

A relative installed firefox 2 and I had firefox 3 beta before which I try to 
have it back.  I already uninstalled Firefox 2. I would like to recover the separators and windows I had in the beta. Cheers. 

Comment 11

[chris hofmann]

looks like we ramped to about 3x on the number of users (up to about 29k) on the first few hours of beta 4 yesterday and the crash started to appear again.  

current about 85 crashes reported and ranked #25 on beta 4.

Comment 12

[Dave Townsend [:mossop]]

This is a fun one. I have some STR that can reliably reproduce this:

bp-9deef670-f432-11dc-8478-001a4bd46e84
bp-700f20d4-f42f-11dc-a60d-001a4bd43ef6

1. Start with a cleanish Windows XP system.
2. Install a Firefox 3 nightly.
3. Run Firefox 3
4. Create a system restore point.
5. Install Firefox 2.0.0.12.
6. Run Firefox 2.0.0.12.
7. Revert back to the system restore point you created.

Now running Firefox 3 will crash on startup.
You can also swap around Firefox 2 and 3 in the instructions above and get
Firefox 2 to crash at the same point, though that is before talkback is able to
catch it.

The crash looks strange because manifestFileURL is null which generally should
never happen, except in this case where manifestURI is null as well. Basically
the attempt to create a uri is failing with NS_ERROR_FACTORY_NOT_REGISTERED
because the component registry is screwed.

The cause is system restore. It is a somewhat picky backup system that only
backs up and restores certain file types. The failure here is because it backs
up *.ini files but not *.dat files. Our component registration cache is in
*.dat files. Our indicator that we need to rebuild the cache is in a *.ini
file. Here is the sequence:

Install and run Firefox 2:
  Firefox spots it is a different version to that last run, creates a new
compatibility.ini, compreg.dat and xpti.dat in the profile.

Revert to system restore point:
  System restore restores the backed up compatibility.ini, the Firefox app,
leaving compreg.dat and xpti.dat in place.

Run Firefox 3:
  Firefox sees it is the same version as that last run (according to
compatibility.ini), so runs. Except that compreg.dat and xpti.dat are a
component registry from Firefox 2.

Comment 13

[(not currently active) Ted Mielczarek]

Would be good to know how many unique users are hitting this crash. Are there that many people using system restore and getting busted by it?

Comment 14

[(not currently active) Ted Mielczarek]

Regardless, we should at least not crash here.

Comment 15

[Benjamin Smedberg]

Bug 292549 has the simple NS_ENSURE_TRUE fix for this particular crash, though I'm afraid that we're probably just pushing out the crash to another location. I'm going to post a patch for renaming compreg.dat->compreg.ini, for consideration.

Comment 16

[Wolfgang Rosenauer [:wolfiR]]

Please see bug 426141. It's probably the same and contains information to hunt it down.

Comment 18

[Benjamin Smedberg]

Landed bug 292549 and these crashes seem like they may have disappeared. Going to mark this FIXED, with some trepidation.

Comment 19

[Wolfgang Rosenauer [:wolfiR]]

With that patch my testcase from bug 426141 is still crashing:
(just a different signature)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b35ac618330 (LWP 6736)]
0x00002b35adcf60f2 in PL_DHashTableFinish (table=0x6d7b10) at pldhash.c:363
363         table->ops->finalize(table);
(gdb) bt
#0  0x00002b35adcf60f2 in PL_DHashTableFinish (table=0x6d7b10) at pldhash.c:363
#1  0x00002b35adb46552 in ~nsChromeRegistry (this=0x6d7ae0) at nsChromeRegistry.cpp:433
#2  0x00002b35adb465f9 in nsChromeRegistry::Release (this=0x6d7b10) at nsChromeRegistry.cpp:450
#3  0x00002b35adb45359 in nsChromeRegistryConstructor (aOuter=<value optimized out>, aIID=@0x2b35ade06b20, 
    aResult=0x7fffff578810) at nsChromeFactory.cpp:49
#4  0x00002b35add2438c in nsComponentManagerImpl::CreateInstanceByContractID (this=<value optimized out>, 
    aContractID=<value optimized out>, aDelegate=0x0, aIID=@0x2b35ade06b20, aResult=0x7fffff578810)
    at nsComponentManager.cpp:1756
#5  0x00002b35add25572 in nsComponentManagerImpl::GetServiceByContractID (this=0x6cf260, 
    aContractID=0x2b35ade05996 "@mozilla.org/chrome/chrome-registry;1", aIID=@0x2b35ade06b20, result=0x7fffff578898)
    at nsComponentManager.cpp:2189
#6  0x00002b35adcf8406 in nsGetServiceByContractID::operator() (this=<value optimized out>, aIID=@0x0, 
    aInstancePtr=0x7fffff578898) at nsComponentManagerUtils.cpp:94
#7  0x00002b35adcf7967 in nsCOMPtr_base::assign_from_gs_contractid (this=0x7fffff5788e0, gs=<value optimized out>, 
    iid=@0x1) at nsCOMPtr.cpp:132
#8  0x00002b35ad5ca0dd in ScopedXPCOMStartup::SetWindowCreator (this=<value optimized out>, 
    native=<value optimized out>) at ../../dist/include/xpcom/nsCOMPtr.h:677
#9  0x00002b35ad5ca372 in ProfileLockedDialog (aProfileDir=0x6af240, aProfileLocalDir=0x6af240, aUnlocker=0x0, 
    aNative=0x65b3b0, aResult=0x7fffff578f40) at nsAppRunner.cpp:1629
#10 0x00002b35ad5ce460 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, 
    aAppData=<value optimized out>) at nsAppRunner.cpp:2067

Comment 20

[Benjamin Smedberg]

Attachment: Clean up the chrome registry more cleanly, rev. 1

The real problem lies elsewhere. This is still just failing less crashily. I promise you, the app isn't going to start!

Comment 21

[Benjamin Smedberg]

Comment on attachment 314923 [details] [diff] [review]
Clean up the chrome registry more cleanly, rev. 1

Fix for crash in horked-startup case, should be very low-risk.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 314923 [details] [diff] [review]
Clean up the chrome registry more cleanly, rev. 1

a1.9=beltzner

Comment 23

[Benjamin Smedberg]

Fixed, again.

Comment 24

[Felix Miata]

FWI might be worth to try to repro, I see this in SUSE Factory's 2008032600 SUSE/2.9.95-4 Firefox/3.0b5 if started normally, but not if appending -P profilename. I have 3 profiles, one for v2, one for SUSE's build, and one for nightlies. 2008041004 trunk does not do this.

I also get a segfault with the SUSE build if I empty ~/.mozilla and start with -profilemanager, but not if started with no command line parameters.

Comment 25

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #20)
> The real problem lies elsewhere. This is still just failing less crashily. I
> promise you, the app isn't going to start!

Fair enough and true. The crash is gone but the "bug" that no Firefox (or profilemanager in my case) is coming up remains. So I guess I'll file a new one.

Comment 26

[Jesse Ruderman]

Wolfgang filed bug 428583.