33344 - Core dump when no write access to dist directory

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Per Lejontand]

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.

Comment 1

[Dawn Endico]

changing from architecture to browser product

Comment 2

[Dawn Endico]

this time for sure

Comment 3

[Gervase Markham [:gerv]]

That file seems to be part of XPCOM.

Gerv

Comment 4

[Martijn Pieters]

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

Comment 5

[Suresh Duddi (gone)]

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.

Comment 6

[Suresh Duddi (gone)]

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.

Comment 7

[Suresh Duddi (gone)]

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

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Suresh Duddi (gone)]

Ok fair. Moving to M20.

Comment 10

[leger]

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

Comment 11

[Decklin Foster]

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

Comment 12

[Ray Whitmer]

This question, like others, seems tied to "Registering Components in XPCOM".

Unless we eliminate autoregistration, this is normal, expected behavior.

Comment 13

[Martijn Pieters]

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.

Comment 14

[Ray Whitmer]

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.

Comment 15

[leger]

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

Comment 16

[Ray Whitmer]

This might be related to bug 43347.

Comment 17

[Martijn Pieters]

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).

Comment 18

[Ray Whitmer]

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

Comment 19

[leger]

Updating QA Contact