16257 - Error with profile manager.

Status: VERIFIED WORKSFORME

(Core :: Preferences: Backend, defect, P3)

Description

[Brian 'netdragon' Bober]

Note: this only happens on the Mozilla build that I downloaded on the 11th of
November. I built it as debug code. It is from M10.

If you delete Mozregistry.dat from the windows directory and run Mozilla, it
will bring up a profile manager window. If you close that window immediately,
you get this error:

APPRUNNER caused an exception 03H in module KERNEL32.DLL at 0167:bff768a5.
Registers:
EAX=00000000 CS=0167 EIP=bff768a5 EFLGS=00000246
EBX=007d0000 SS=016f ESP=008dfbb8 EBP=008dfbbc
ECX=0000003e DS=016f ESI=817d88a0 FS=4ce7
EDX=00daf100 ES=016f EDI=00000000 GS=0000
Bytes at CS:EIP:
c3 cc cc 55 8b ec 56 57 68 c0 94 fc bf e8 01 d9
Stack dump:
1000ce69 008dfbcc 1000cf58 00daf100 0000003e 008dfc08 00da8c4d 00daf0bc 00daf0ec
00daf100 0000003e 00000009 80070057 00cc70b0 00000000 78043e01

The output of the Mozilla window looks like this:

nsNativeComponentLoader: autoregistering C:\PROGRAMMING\MOZILLA\SOURCE\MOZILLA\D
IST\WIN32_D.OBJ\BIN\components
nsNativeComponentLoader: autoregistering succeeded
started appcores
initialized appshell
plugins at: C:\PROGRAMMING\MOZILLA\SOURCE\MOZILLA\DIST\WIN32_D.OBJ\BIN\plugins
Note: styleverifytree is disabled
Note: frameverifytree is disabled
got a request
Start reading in bookmarks.html
Finished reading in bookmarks.html  (110000 microseconds)
# of builders: 1
# of builders: 1

The build I got from you says this:

got a request
Setting content window
browser.startup.page = 1
startpage = www.mozilla.org
failed to set the page title.
failed to set the page title.
failed to set the page title.
got observer service
added observer
failed to set the page title.
Init!
adding "http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf" to
 the tree
http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf: setting po
ll interval to 300sec.
adding "rdf:msgnotifications" to the tree
adding "rdf:xpinstall-update-notifier" to the tree
an exception occurred trying to load "rdf:xpinstall-update-notifier":
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [n
sIRDFService.GetDataSource]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  locatio
n: "JS frame :: chrome://sidebar/content/flash.js :: FlashInit :: line 79"  data
: no]

No error occurs.

I debugged the code and it had entered:

NS_COM void nsDebug::NotYetImplemented(const char* aMessage,
                                       const char* aFile, PRIntn aLine)
{
  DBG_LOG(gDebugLog, PR_LOG_ERROR,
          ("NotYetImplemented: \"%s\" at file %s, line %d", aMessage,
           aFile, aLine));
  Break(aFile, aLine);
}

on line 184 of mozilla\xpcom\base\nsDebug.cpp from

inline nsIFileSpec* NS_LocateFileOrDirectory(PRUint32 selector)
{
    nsresult rv;
    nsIFileSpec* spec = nsnull;
    NS_WITH_SERVICE(nsIFileLocator, locator, NS_FILELOCATOR_PROGID, &rv);
    if (NS_SUCCEEDED(rv) && locator)
    {
	    rv = locator->GetFileLocation(selector, &spec);
	    NS_ASSERTION(NS_SUCCEEDED(rv), "ERROR: File locator cannot locate
file.");
    }
    return spec;
}




in line 54 of nslFileLocater.h

called from:





nsresult nsPref::useDefaultPrefFile()
//------------------------------------------------------------------------------
----------
{
    nsIFileSpec* prefsFile =
NS_LocateFileOrDirectory(nsSpecialFileSpec::App_PreferencesFile50);
    nsresult rv = NS_OK;
    if (!prefsFile)
    {
	    // There is no locator component. Or perhaps there is a locator, but
the
	    // locator couldn't find where to put it. So put it in the cwd (NB,
viewer comes here.)
        // #include nsIComponentManager.h
        rv = nsComponentManager::CreateInstance(
        	(const char*)NS_FILESPEC_PROGID,
        	(nsISupports*)nsnull,
        	(const nsID&)nsIFileSpec::GetIID(),
        	(void**)&prefsFile);
        NS_ASSERTION(NS_SUCCEEDED(rv), "ERROR: Could not make a file spec.");
	    if (!prefsFile)
	    	return NS_ERROR_FAILURE;
	    prefsFile->SetUnixStyleFilePath("default_prefs.js"); // in default
working directory.
    }
    if (Exists(prefsFile)) {
        rv = ReadUserPrefsFrom(prefsFile);
        NS_RELEASE(prefsFile);
        return rv;
    }

    // need to save the prefs now
    mFileSpec = prefsFile; // Already addreffed when retrieved.
    rv = SavePrefFile();

    return rv;
} // nsPref::useDefaultPrefFile


in mozilla\modules\libpref\src\nsPref.cpp line 196

Comment 1

[selmer (gone)]

The stack trace looks like prefs, not profiles...

Comment 2

[selmer (gone)]

Neeti, can you take a look at this and see if it's really prefs?

Comment 3

[neeti]

I need more clarification on this bug. When is the profile manager window
closed. Do you close it after a new profile is created? The output of the
mozilla window you sent does not have the following two lines

got a request
ProfileName : mozProfile
ProfileDir  : F:\seamonkey\mozilla\dist\Users50\mozProfile

Can anyone tell me how to reproduce this crash?
Thanks,
Neeti

Comment 4

[neeti]

Grace,
Can you reproduce this crash?

Neeti

Comment 5

[Brian 'netdragon' Bober]

I got the error by clicking the X in communicator profile manager after I
deleted "mozregistry.dat" and ran apprunner. Note the date of build. Maybe the
bug no longer exists.

This is what the apprunner window shows before I click the X:

nsNativeComponentLoader: autoregistering C:\PROGRAMMING\MOZILLA\SOURCE\MOZILLA\D
IST\WIN32_D.OBJ\BIN\components
nsNativeComponentLoader: autoregistering succeeded
started appcores
initialized appshell
plugins at: C:\PROGRAMMING\MOZILLA\SOURCE\MOZILLA\DIST\WIN32_D.OBJ\BIN\plugins
Note: styleverifytree is disabled
Note: frameverifytree is disabled
got a request
Start reading in bookmarks.html
Finished reading in bookmarks.html  (270000 microseconds)
run LoadDetectorsMenu()

Comment 6

[neeti]

I am marking this bug as WORKSFORME, since I am unable to reproduce the crash.

Comment 7

[Grace Bush]

I am going to verify WORKSFORME.  I was unable to find a build for Oct11th (I
assume that is the one you meant boberb.  I tried deleting mozregistry.dat BUT
not the Users50 directory, thinking that may cause a problem, but I am still
able to exit gracefully on recent builds. Generally, if you delete
mozregistry.dat you want to remove users50 also.

Comment 8

[leger]

Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.