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

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

mcmullen might have a better idea on this.

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

I was still seeing this on Friday night I think.

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

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

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

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.

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.

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.

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.

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

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?

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.

M8

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

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

I will take this one.

marking works for me.

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?

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

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