Solaris 2.6. gcc 2.7.2. Build/pull from 9am PST on March 12, 1999. UMR: Uninitialized memory read: * This is occurring while in: strlen [rtlib.o] nsFileSpecHelpers::StringAssign(char*&,const char*) [nsFileSpec.cpp:112] nsFileSpecHelpers::Canonify(char*&,int) [nsFileSpecUnix.cpp:76] nsFileSpec::operator =(const char*) [nsFileSpec.cpp:747] GetCurrentProcessDirectory(nsFileSpec&) [nsSpecialSystemDirectory.cpp:125] nsSpecialSystemDirectory::operator =(nsSpecialSystemDirectory::SystemDirectories) [nsSpecialSystemDirectory.cpp:203] nsSpecialSystemDirectory::nsSpecialSystemDirectory(nsSpecialSystemDirectory::Sys temDirectories) [nsSpecialSystemDirectory.cpp:143] NS_SetupRegistry [nsSetupRegistry.cpp:277] NS_SetupRegistry_1 [nsSetupRegistry.cpp:93] main [nsAppRunner.cpp:120] _start [crt1.o] * Reading 41 bytes from 0xefffec28 on the stack (39 bytes at 0xefffec29 uninit). * Address 0xefffec28 is local variable "buffer" in function nsFileSpecHelpers::Canonify(char*&,int).

This isn't specific to this usage as I though ... looking around, I see another incidence of this as well: **** Purify instrumented ./apprunner.pure (pid 29126) **** UMR: Uninitialized memory read: * This is occurring while in: strlen [rtlib.o] nsFileSpecHelpers::StringAssign(char*&,const char*) [nsFileSpec.cpp:112] nsFileSpecHelpers::Canonify(char*&,int) [nsFileSpecUnix.cpp:76] nsFileSpec::operator =(const char*) [nsFileSpec.cpp:747] GetCurrentProcessDirectory(nsFileSpec&) [nsSpecialSystemDirectory.cpp:125] nsSpecialSystemDirectory::operator =(nsSpecialSystemDirectory::SystemDirectories) [nsSpecialSystemDirectory.cpp:203] nsSpecialSystemDirectory::nsSpecialSystemDirectory(nsSpecialSystemDirectory::Sys temDirectories) [nsSpecialSystemDirectory.cpp:143] BookmarkDataSourceImpl::ReadBookmarks() [nsBookmarkDataSource.cpp:828] BookmarkDataSourceImpl::Init(const char*) [nsBookmarkDataSource.cpp:727] ServiceImpl::GetDataSource(const char*,nsIRDFDataSource**) [nsRDFService.cpp:925] RDFXULBuilderImpl::CreateBuilder(const nsID&,nsIContent*,const nsString&) [nsRDFXULBuilder.cpp:1946] RDFXULBuilderImpl::CreateXULElement(nsIRDFResource*,int,nsIAtom*,nsIContent**) [nsRDFXULBuilder.cpp:1756] RDFXULBuilderImpl::CreateElement(nsIRDFResource*,nsIContent**) [nsRDFXULBuilder.cpp:1438] RDFXULBuilderImpl::AppendChild(nsIContent*,nsIRDFNode*) [nsRDFXULBuilder.cpp:1327] RDFXULBuilderImpl::CreateContents(nsIContent*) [nsRDFXULBuilder.cpp:568] XULDocumentImpl::CreateContents(nsIContent*) [nsXULDocument.cpp:1988] RDFElementImpl::EnsureContentsGenerated()const [nsRDFElement.cpp:2327] RDFElementImpl::ChildCount(int&)const [nsRDFElement.cpp:1322] nsCSSFrameConstructor::ProcessChildren(nsIPresContext*,nsIContent*,nsIFrame*,nsA bsoluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:269] nsCSSFrameConstructor::ConstructXULFrame(nsIPresContext*,nsIContent*,nsIFrame*,n sIAtom*,nsIStyleContext*,nsAbsoluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsol uteItems&,int&) [nsCSSFrameConstructor.cpp:2277] nsCSSFrameConstructor::ConstructFrame(nsIPresContext*,nsIContent*,nsIFrame*,nsAb soluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:2916] nsCSSFrameConstructor::ProcessChildren(nsIPresContext*,nsIContent*,nsIFrame*,nsA bsoluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:275] nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresContext*,const nsStyleDisplay*,nsIContent*,nsIFrame*,nsIStyleContext*,nsAbsoluteItems&,nsFrameI tems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:2682] nsCSSFrameConstructor::ConstructFrame(nsIPresContext*,nsIContent*,nsIFrame*,nsAb soluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:2930] nsCSSFrameConstructor::ProcessChildren(nsIPresContext*,nsIContent*,nsIFrame*,nsA bsoluteItems&,nsFrameItems&,nsAbsoluteItems&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:275] nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresContext*,nsIContent*,nsIF rame*,nsIStyleContext*,nsIFrame*&,nsAbsoluteItems&) [nsCSSFrameConstructor.cpp:1450] nsCSSFrameConstructor::ContentInserted(nsIPresContext*,nsIContent*,nsIContent*,i nt) [nsCSSFrameConstructor.cpp:3310] StyleSetImpl::ContentInserted(nsIPresContext*,nsIContent*,nsIContent*,int) [nsStyleSet.cpp:747] PresShell::InitialReflow(int,int) [nsPresShell.cpp:829] XULDocumentImpl::StartLayout() [nsXULDocument.cpp:3015] * Reading 41 bytes from 0xefffc9b8 on the stack (39 bytes at 0xefffc9b9 uninit). * Address 0xefffc9b8 is local variable "buffer" in function nsFileSpecHelpers::Canonify(char*&,int).

Ah! my first file bug in bugzilla! Thank you! Fix will occur before monday morning. Accepting.

OK, I'm not running solaris, but nsSystemDirectory is the only client of nsFileSpec showing this problem, and the string it is trying to assign is obtained in nsSpecialSystemDirectory.cpp line 122, thus: char *moz5 = getenv("MOZILLA_FIVE_HOME"); Is this returning uninitialized memory? Reassigning to the author of this line, dp.

This is happening at line number 125 which is: else { if (getcwd(buf, sizeof(buf))) { --> aFileSpec = buf; return; } } Why do you think 122 is what is doing it ?

My mistake. The line numbers in my tree do not line up with the repository (there are changes). However, there are only two ways this crash could occur (1) the assignee has an uninitialized string, or (2) the assigned string is incorrect. I was looking for (2). However, (1) is possible, and I wonder if you would try this as a fix (the only change is the (const char*) cast. *************** *** 144,154 **** } nsSpecialSystemDirectory::~nsSpecialSystemDirectory() { } void nsSpecialSystemDirectory::operator = (SystemDirectories aSystemSystemDirectory) { ! *this = nsnull; switch (aSystemSystemDirectory) { --- 153,167 ---- } nsSpecialSystemDirectory::~nsSpecialSystemDirectory() { } void nsSpecialSystemDirectory::operator = (SystemDirectories aSystemSystemDirectory) { ! *this = (const char*)nsnull; switch (aSystemSystemDirectory) {

I just checked in mozilla/base/src/nsSpecialSystemDirectory.cpp and mozilla/base/ public/nsSpecialSystemDirectory.h. This includes the alleged fix. Bruce, could you pull again?

I had manually applied that fix at dp's request. It didn't fix it. The code isn't crashing btw, it is just reading memory that hasn't been initialized with a value. The memory that isn't properly initialized is in nsFileSpecHelpers::Canonify() ... I'd suspect something might be odd in there, perhaps with the fact that 'buffer' isn't getting initialized much at all in the call to realpath().

Resolved as FIXED. Bruce, open this back up against John if his latest change didn't actually fix the problem.

As per my comments of 14:45pm on March 12, 1999, this bug isn't fixed with the suggested fix by mcmullen.

Not really fixed, then! Well, buffer is initialized to an empty string. What else should it be initialized to? The stack crawl above suggests that the uninitialized memory is read in the call to StringAssign. Since ioPath is passed in to this function, the badness could be happening long before Canonify is called (ie, I'm assuming that the ioPath passed in is the culprit. It should be NULL in this particular invocation. Any chance you can check this with a debugger? Thanks.

Cleared resolution of FIXED. John, Bruce, dp, Should we fix this now, i.e. for M3, or should I mark this for M4?

I will very shortly be checking in all these files again, with quite a few bug fixes. Perhaps the bug will magically go away -- but somehow I doubt it. But you should debug with the latest pull.

Set target milestone to M4. OK, since we're not sure when this can actually be fixed ... :-)

Also, it's not a crashing but, it just reads uninitialized memory (not even reading illegal memory), so I think it's less than critcal.

.n/crashing but/crashing bug/

seems to be a bug in realpath() on Solaris possibly. doing a memset() to 0 on buffer clears it up. until then, the contents of buffer look odd/not good.

Did I dream I already checked this in? Well, I've done so again now. Buffer cleared with 0, solaris only.

I really don't like this fix much. Will attempt to follow up with Sun when I get a contact there (hint hint hint). Wonder what happens under purify on Irix or NT?