12186 - [BLOCKER] assertion failure in GetProfileDirectory causes crash

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Stephen P. Morse]

Threw away existing mozilla directory, pulled a fresh tree as of about 6PM this
evening, and built it.  Deleted mozregistry.dat.

Went to execute.  Got into profile manager, entered a profile name, and
clicked on finish.  Got a crash with the stack trace shown below.  Tried
re-executing.  Didn't get profile manager this time (because mozregistry
was created) but still got the crash.

Problem is the assert in GetProfileDirectory of nsFileLocations.cpp, namely:

NS_ASSERTION(*gProfileDir == currProfileDirSpec, "Profile spec does not
match!");

and gProfileDir is 0 at this time.  Commenting out the above line at least lets
the browser start up.  But there is no profile directory so many things don't
work.
nsSimpleCharString::Length() line 257 + 12 bytes
nsSimpleCharString::IsEmpty() line 255 + 15 bytes
nsFileSpec::operator==(const nsFileSpec & {...}) line 968 + 11 bytes
GetProfileDirectory(nsFileSpec & {...}) line 141 + 16 bytes
nsSpecialFileSpec::operator=(nsSpecialFileSpec::Type
App_UserProfileDirectory50) line 299 + 9 bytes
nsSpecialFileSpec::nsSpecialFileSpec(nsSpecialFileSpec::Type
App_UserProfileDirectory50) line 226
nsSpecialFileSpec::operator=(nsSpecialFileSpec::Type
App_PrefsDirectory50) line 248 + 13 bytes
nsSpecialFileSpec::nsSpecialFileSpec(nsSpecialFileSpec::Type
App_PrefsDirectory50) line 226
nsSpecialFileSpec::operator=(nsSpecialFileSpec::Type
App_PreferencesFile50) line 346 + 13 bytes
nsFileLocator::GetFileLocation(nsFileLocator * const 0x00a9ad40,
unsigned int 66539, nsIFileSpec * * 0x0012fe0c) line 467
NS_LocateFileOrDirectory(unsigned int 66539) line 54 + 20 bytes
nsPref::useDefaultPrefFile() line 268 + 10 bytes
nsPref::ReadUserPrefs(nsPref * const 0x00a54eb0) line 397 + 8 bytes
main1(int 1, char * * 0x00a31af0) line 702
main(int 1, char * * 0x00a31af0) line 828 + 13 bytes
mainCRTStartup() line 338 + 17 bytes
K

Comment 1

[Chris Waterson]

This is a Win32-specific profile manager problem. To reproduce:

1. Delete c:\winnt\mozregistry.dat
2. rm -rf d:\seamonkey\mozilla\dist\users50 (or wherever your profiles are
stored)

Re-run profile manager. It will not create a new Users50 directory. Reassigning
to selmer; cc'ing sspitzer.

Comment 2

[Chris Waterson]

Escalate.

Comment 3

[Chris Waterson]

The crash is brain dead. The NS_ASSERTION() attempts to dereference a null
pointer. But this isn't the real problem.

So it looks like the directory name is not being saved into mozregistry.dat
when the profile wizard exists. I fail at line 344 of nsProfile.cpp -- it can't
walk the "directory" key in the registry.

Comment 4

[Doug Turner (:dougt)]

possibly related(?) 12107

Comment 5

[Chris Waterson]

Okay, this was caused by GFX text widgets. Reassigning to kmcclusk so that he
can make sure that this works before turning on GFX widgets again.

Comment 6

[Chris Waterson]

Kevin: Just to clarify. The problem seems to be that the text widget (when
used as a simple entry field) is appending a newline to its value; e.g.,
instead of "foo" you get back "foo\n" as the value.

Comment 7

[selmer (gone)]

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

Comment 8

[selmer (gone)]

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

Comment 9

[Simon Fraser [no longer active]]

cc:ing akkana, in case this is cased by the text encoding.

Comment 10

[Akkana Peck]

It's possible (that it has to do with the document encoder).  Can someone
suggest a simple test case so I can look into it now that gfx text widgets have
been turned off again?

We also have a known bug involving extra newlines showing up in the plaintext
editor, which Joe is looking at, so he should definitely be on the cc list.

Comment 11

[buster]

I think the problem is that the enter-key return is getting through to the
editor through the text control.  The text control should hide enter-key (and
tab-key) input.  I'm working on this now.  If there are other problems after
that, then I'll write a new bug.  But this one is mine.

Comment 12

[buster]

fix checked in this morning.  This can be verified by manually turning on gfx
text controls in the code (nsPresContext.cpp), or waiting until Kevin turns them
back on by default.

Comment 13

[buster]

clearing whiteboard, it's been fixed for a few days

Comment 14

[leger]

Adding crash keyword

Comment 15

[jerone]

verfied on build 2001071004 PC/win95