Building mozilla on my debian 2.1 (i386) i discovered som problems while launching the build binary, ie a segfault. I tracked that baby down to nsNativeComponentLoader::AutoRegisterComponent, just about: rv = mCompMgr->RegistryLocationForSpec(component, getter_Copies(persistentDescriptor)); Which dump's since mCompMgr==NULL, I dont know why but that's what I want help with. Checking for NULL and setting rv=NS_ERROR_FAILURE if so gave me a bunch of other results, probably expected but ... nsNativeComponentLoader: autoregistering succeeded ###!!! ASSERTION: Cannot obtain unix toolkit service.: 'rv == NS_OK', file ../../webshell/tests/viewer/nsSetupRegistry.cpp, line 274 ###!!! Break: at file ../../webshell/tests/viewer/nsSetupRegistry.cpp, line 274 NS_SetupRegistry() MOZ_TOOLKIT=error, WIDGET_DLL=error, GFX_DLL=error ###!!! ASSERTION: failed to get command line service: 'NS_SUCCEEDED(rv)', file nsAppRunner.cpp, line 666 ###!!! Break: at file nsAppRunner.cpp, line 666 Could not obtain CmdLine processing service ###!!! ASSERTION: failed to get prefs, so unable to save them: 'NS_SUCCEEDED(rv)', file nsAppRunner.cpp, line 882 ###!!! Break: at file nsAppRunner.cpp, line 882 Program received signal SIGSEGV, Segmentation fault. 0x40102cbb in nsHashtable::Get () at nsHashtable.cpp:90 Found this a while back, but it still breaks on as late as tonights (20000326) cvs checkout.

changing from architecture to browser product

this time for sure

That file seems to be part of XPCOM. Gerv

I just wanted to file a bug on this. In my case mCompMgr is 0x0, because the dist dir wasn't writeable and compnent.reg could not be written. In nsComponentManagerImpl::PlatformInit a call is made to mRegistry->OpenWellKnownRegistry which should cause the component.reg file to be created. If this fails (NS_ERROR_FAIL is returned), PlatformInit bails out returning the rv. This means that the call to mNativeComponentLoader->Init, which should set mCompMgr in the Component Loader, is never made. Because the return value of PlatformInit is ignored, this is never detected. Later on the NativeComponentLoader tries to register a library with the Component Manager, and thus tries to access address 0x0. I managed to fix this by giving write access to the dist dir to the user running Mozilla. Steps to reproduce: 1/ rm component.reg 2/ chmod -w . 3/ ./mozilla

Yeah the first time around (think installation), we need write access to create the registry. But next time around we shouldn't require it. Changing summary.

So I just tried this: chmod a-w component.reg ./mozilla-bin and that worked. We require write access to the directory of installation the first time around. Once we have an installer, the installer will take care of that. For every subsequent run, we only need read access. Dan, one wierd thing I noticed was that if there was write access to dist/bin libreg changed the date on component.reg Can we change that behaviour.

First time write is a requirement and is equivalent to an installation run. So wontfix.

You can't mark a crash as WONTFIX! Yes, we require write access at installation time, but if we can't we should fail gracefully. Marking "helpwanted" since you obviously don't want to deal with this at this time.

Ok fair. Moving to M20.

Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on sabbatical. rayw is now default assignee for these components.

*** Bug 43512 has been marked as a duplicate of this bug. ***

This question, like others, seems tied to "Registering Components in XPCOM". Unless we eliminate autoregistration, this is normal, expected behavior.

What? A crash is norma, expected behaviour? I'd expect a graceful error message myself. 'Cannot autoregister, no write access' is the least any user'd expect.

I didn't mean it that way. Clearly some level needs to be fixed to behave more-gracefully. It is clear that if the directory is unwritable, at least persistent registrations and autoregistration need to fail, and if no file containing registrations already exists, then the whole application needs to fail. XPCOM should probably be expected to add UI such as localizable error text, but rather just report errors at the appropriate points and expect the calling application to check returns, and, indeed, get a crash otherwise. We need to work out exactly what each side should expect in this case.

rayw, does rusty's patch in 43512 fix this? Looks like similar problems.

This might be related to bug 43347.

That bug is indeed a duplicate of this one, except that bug #43347 has a patch that should fix this issue (or at least moves the responsibility for handling the error up the call stack).

The patch in 43347 was applied, which we believe is the (first) fix to this, as well. There may be down-stream problems remaining.

Updating QA Contact