Topcrash: [@ nsChromeRegistry::CheckForNewChrome] during startup

RESOLVED FIXED in mozilla1.9

Status

()

Toolkit
Startup and Profile System
P2
critical
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: mats, Assigned: Benjamin Smedberg)

Tracking

({crash, topcrash})

Trunk
mozilla1.9
x86
All
crash, topcrash
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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
Flags: blocking1.9?
(Assignee)

Comment 1

11 years ago
The crash appears to have mostly gone away (I don't know why). Please re-nominate if the stats come back.
Flags: blocking1.9?
(Reporter)

Updated

11 years ago
Keywords: topcrash

Comment 2

11 years ago
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
Flags: blocking1.9?
OS: Windows XP → All

Updated

11 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
(Assignee)

Comment 3

11 years ago
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.
Assignee: nobody → benjamin
Keywords: qawanted
It's still, currently, the number 10 topcrash for Firefox 3 Beta 3.
Keywords: topcrash

Comment 5

10 years ago
its moving up in the rankings.  now at #7 for beta3
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0b3
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

10 years ago
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....

Please renom if the numbers come back after beta 4
Flags: tracking1.9+

Comment 9

10 years ago
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
Flags: blocking1.9?

Comment 10

10 years ago
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

10 years ago
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.
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.
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?
Regardless, we should at least not crash here.
Flags: blocking1.9? → blocking1.9+
Priority: P3 → P2
Keywords: qawanted
(Assignee)

Comment 15

10 years ago
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.
Please see bug 426141. It's probably the same and contains information to hunt it down.
Duplicate of this bug: 426141
(Assignee)

Comment 18

10 years ago
Landed bug 292549 and these crashes seem like they may have disappeared. Going to mark this FIXED, with some trepidation.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 20

10 years ago
Created attachment 314923 [details] [diff] [review]
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!
Attachment #314923 - Flags: review?(dtownsend)

Updated

10 years ago
Attachment #314923 - Flags: review?(dtownsend) → review+
(Assignee)

Comment 21

10 years ago
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.
Attachment #314923 - Flags: approval1.9?
Comment on attachment 314923 [details] [diff] [review]
Clean up the chrome registry more cleanly, rev. 1

a1.9=beltzner
Attachment #314923 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 23

10 years ago
Fixed, again.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 24

10 years ago
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.
(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

10 years ago
Wolfgang filed bug 428583.

Updated

10 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Crash Signature: [@ nsChromeRegistry::CheckForNewChrome]
You need to log in before you can comment on or make changes to this bug.