6098 - Solaris: First-time startup dumps core, nsSpecialFileSpec

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect, P3)

Description

[ckerr]

platform: Solaris 5.7
build: mozilla May 05 19:24
synopsis: first-time startup causes crash.
reproducable: yes; blow away ~/.mozilla to simulate first-time startup
url: n/a

first dump:

> (10:23:11)(ckerr opup01)(~/eval/package): ./apprunner
> Warning: MOZILLA_FIVE_HOME not set.
> nsComponentManager: Using components dir: /users/ckerr/eval/package/components
> nsComponentManager: Creating Directory /users/ckerr/.mozilla
> Registered Ok
> width was not set
> height was not set
> Segmentation Fault (core dumped)
> (gdb) bt
> #0  0xfe2f06d0 in memcpy () from
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> #1  0xff2fed08 in CharImpl::write () from
/users/ckerr/eval/package/./libraptorbase.so
> #2  0xff2fef0c in BasicStringImpl::Write () from
/users/ckerr/eval/package/./libraptorbase.so
> #3  0xff2fb5d0 in nsOutputStream::write () from
/users/ckerr/eval/package/./libraptorbase.so
> #4  0xff2fb61c in nsOutputStream::operator<< () from
/users/ckerr/eval/package/./libraptorbase.so
> #5  0xff2fa584 in operator<< () from
/users/ckerr/eval/package/./libraptorbase.so
> #6  0xfe163144 in nsProfile::SetProfileDir () from
/users/ckerr/eval/package/components/libprofile.so
> #7  0xff371f50 in nsAppShellNameSet::AddNameSet () from
/users/ckerr/eval/package/./libnsappshell.so
> #8  0xff3723bc in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #9  0xff3721ac in nsSpecialFileSpec::nsSpecialFileSpec () from
/users/ckerr/eval/package/./libnsappshell.so
> #10 0xff3722fc in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #11 0xff3721ac in nsSpecialFileSpec::nsSpecialFileSpec () from
/users/ckerr/eval/package/./libnsappshell.so
> #12 0xff372444 in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #13 0xff37273c in nsFileLocator::GetFileLocation () from
/users/ckerr/eval/package/./libnsappshell.so
> #14 0xfe8ad5ec in nsPref::useDefaultPrefFile () from
/users/ckerr/eval/package/./libpref.so
> #15 0xfe8adad4 in nsPref::StartUp () from
/users/ckerr/eval/package/./libpref.so
> #16 0xfe8ad8bc in nsPref::GetInstance () from
/users/ckerr/eval/package/./libpref.so
> #17 0xfe8ae98c in nsPrefFactory::CreateInstance () from
/users/ckerr/eval/package/./libpref.so
> #18 0xff33d450 in nsComponentManagerImpl::CreateInstance () from
/users/ckerr/eval/package/./libxpcom.so
> #19 0xff33f598 in nsComponentManager::CreateInstance () from
/users/ckerr/eval/package/./libxpcom.so
> #20 0xff33fdd0 in nsServiceManagerImpl::GetService () from
/users/ckerr/eval/package/./libxpcom.so
> #21 0xff34046c in nsServiceManager::GetService () from
/users/ckerr/eval/package/./libxpcom.so
> #22 0x1dbb4 in main ()

second dump (after rm'ing .mozilla):

> (10:28:36)(ckerr opup01)(~/eval/package): ./apprunner
> Warning: MOZILLA_FIVE_HOME not set.
> nsComponentManager: Using components dir: /users/ckerr/eval/package/components
> nsComponentManager: Creating Directory /users/ckerr/.mozilla
> Registered Ok
> width was not set
> height was not set
> Segmentation Fault (core dumped)
> (gdb) bt
> #0  0xfe2f06d0 in memcpy () from
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> #1  0xff2fed08 in CharImpl::write () from
/users/ckerr/eval/package/./libraptorbase.so
> #2  0xff2fef0c in BasicStringImpl::Write () from
/users/ckerr/eval/package/./libraptorbase.so
> #3  0xff2fb5d0 in nsOutputStream::write () from
/users/ckerr/eval/package/./libraptorbase.so
> #4  0xff2fb61c in nsOutputStream::operator<< () from
/users/ckerr/eval/package/./libraptorbase.so
> #5  0xff2fa584 in operator<< () from
/users/ckerr/eval/package/./libraptorbase.so
> #6  0xfe163144 in nsProfile::SetProfileDir () from
/users/ckerr/eval/package/components/libprofile.so
> #7  0xff371f50 in nsAppShellNameSet::AddNameSet () from
/users/ckerr/eval/package/./libnsappshell.so
> #8  0xff3723bc in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #9  0xff3721ac in nsSpecialFileSpec::nsSpecialFileSpec () from
/users/ckerr/eval/package/./libnsappshell.so
> #10 0xff3722fc in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #11 0xff3721ac in nsSpecialFileSpec::nsSpecialFileSpec () from
/users/ckerr/eval/package/./libnsappshell.so
> #12 0xff372444 in nsSpecialFileSpec::operator= () from
/users/ckerr/eval/package/./libnsappshell.so
> #13 0xff37273c in nsFileLocator::GetFileLocation () from
/users/ckerr/eval/package/./libnsappshell.so
> #14 0xfe8ad5ec in nsPref::useDefaultPrefFile () from
/users/ckerr/eval/package/./libpref.so
> #15 0xfe8adad4 in nsPref::StartUp () from
/users/ckerr/eval/package/./libpref.so
> #16 0xfe8ad8bc in nsPref::GetInstance () from
/users/ckerr/eval/package/./libpref.so
> #17 0xfe8ae98c in nsPrefFactory::CreateInstance () from
/users/ckerr/eval/package/./libpref.so
> #18 0xff33d450 in nsComponentManagerImpl::CreateInstance () from
/users/ckerr/eval/package/./libxpcom.so
> #19 0xff33f598 in nsComponentManager::CreateInstance () from
/users/ckerr/eval/package/./libxpcom.so
> #20 0xff33fdd0 in nsServiceManagerImpl::GetService () from
/users/ckerr/eval/package/./libxpcom.so
> #21 0xff34046c in nsServiceManager::GetService () from
/users/ckerr/eval/package/./libxpcom.so
> #22 0x1dbb4 in main ()

Comment 1

[don]

Chris, aren't you working on a bug like this?

Comment 2

[chris hofmann]

mcmullen might have a better idea on this.

Comment 3

[mcmullen]

Moving to M7, because I think this has actually been fixed. Chris, Bruce, could
you check if this is so, please?

Comment 4

[Bruce Mitchener]

I was still seeing this on Friday night I think.

Comment 5

[mcmullen]

OK, it's not fixed. But I have to do this xpcom reorganization, and won't be
fixing this for M6

Comment 6

[don]

This is rather low priority.  Let's move it to M8 and see if anybody screams.

Comment 7

[Chris McAfee]

Still happens on Solaris, seems to work on Linux.
mString gets initialized, and then shows up NULL for the write() call.

Comment 8

[Bruce Mitchener]

Can we move this back to M7?  This is now happening on _every_ startup for
apprunner, and so I can't do any work on Solaris at all.  This is seemingly less
than optimal since I can't purify because of this.  Any ideas on work arounds?

I'll look into the problem.

Some details though:
I get this null pointer write crash when starting up just as './apprunner.pure'
When starting as './apprunner.pure -P Default' or otherwise specifying a profile
to use, it crashes in main() when printing the profile directory with a null
pointer read (on the currProfileDirSpec.GetCString() result).  Moving that
printf() inside of the check of the NS_SUCCEEDED(rv) directly after it restores
things to the state where it crashes from the null pointer write that you get if
you specify no profile on the command line.

Comment 9

[Bruce Mitchener]

Attachment: nsProfile.cpp patch

Comment 10

[Bruce Mitchener]

Attached a fix that seems to work.  This stops an nsnull from being used to
initialize the nsOutputStream and then life seems much better. Cc'ing shaver at
his request and racham as racham has been involved with nsProfile.cpp of late.

Comment 11

[shaver-do-not-use-this-account]

If this fix is good (and I have no reason to believe it's not, unless there are
clever string things to be doing to avoid an allocation), can someone land it
for M7?  It'd be nice to knock this bug off instead of having it linger until
M8.

Comment 12

[mcmullen]

I'm moving this to M7.



However, this patch may prevent the crash, but it is not "correct".

nsStringOutputStream is designed to accept a null input string, and apparently

does not handle it correctly. Initializing it with a nonempty string first (one

whose contents are irrelevant...) may work around the problem, but it does not

solve the real problem.

Comment 13

[Chris McAfee]

Ok this patch appears to fix the crash for me,
I think we should check this in.  McMullen,
let me know if you want me to check this in.
-Chris x6705

Comment 14

[mcmullen]

I suppose you could check it in, but it's wrong in two ways. One, in the way

above. Two, it nsCRT::frees the string, whereas if nsOutputStringStream needs to

reallocate, it uses new[]. If you check it in, this bug will still really be

around. As I said, initializing an nsOutputStringStream with a null string is

supposed to work.



And why does this happen only on Solaris? Does the compiler have problems with a

data member which is a reference to a pointer?

Comment 15

[Chris McAfee]

I checked in the Solaris workaround patch bruce supplied,
leaving this bug open awaiting a real fix.  mcmullen should
probably move this off the M7 radar now.  No longer a blocker.

Comment 16

[mcmullen]

M8

Comment 17

[Bruce Mitchener]

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

Comment 18

[Bruce Mitchener]

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

Comment 19

[Chris McAfee]

I will take this one.

Comment 20

[Chris McAfee]

marking works for me.

Comment 21

[Bruce Mitchener]

Should we open a new bug for the case of Solaris (and Linux?) not handling a
stream with a null name while Mac and Win32 do as John pointed out?

Comment 22

[Chris McAfee]

new bug is http://bugzilla.mozilla.org/show_bug.cgi?id=9311
CC-d bruce & shaver.

Comment 23

[Eli Goldberg]

Bulk moving to XPCOM, in preparation for removal of XP File Handling component. 
(XPFH has received two bugs in ~5 months, and is no longer in active use.)