Closed Bug 391311 Opened 13 years ago Closed 12 years ago
Topcrash: [@ ns
Chrome Registry::Check For New Chrome] during startup
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
The crash appears to have mostly gone away (I don't know why). Please re-nominate if the stats come back.
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
OS: Windows XP → All
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
It's still, currently, the number 10 topcrash for Firefox 3 Beta 3.
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.
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
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 18.104.22.168 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
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 22.214.171.124 e o computador estava firefox 3 beta, o qual desejo manter como estava. --> Based on information previously sent, my relative installed Firefox 126.96.36.199 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.
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 188.8.131.52. 6. Run Firefox 184.108.40.206. 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
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.
Landed bug 292549 and these crashes seem like they may have disappeared. Going to mark this FIXED, with some trepidation.
Status: NEW → RESOLVED
Closed: 12 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 → ---
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)
Attachment #314923 - Flags: review?(dtownsend) → review+
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+
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
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.
Wolfgang filed bug 428583.
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.