Closed Bug 64929 Opened 25 years ago Closed 24 years ago

Existing Profiles crash when launching if trunk build installed in previous branch build directory

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: esther, Assigned: javi)

Details

On my win ME system & win98 system: Using trunk build 01102001 installed in the same directory where I previously had the branch build 01-04-2001, existing profile crash when launching. Note: New Profiles launch OK. I had removed the branch build using Windows Explorer by deleting the Netscape 6 sub directory. If I had uninstalled instead of removing the directory, I had no problem. Also there was no problem going from RTM build to Branch build. New Profiles launch OK 1. Install the Branch build in a directory and use existing profiles. (I had a directory called "/seacurrent". "Netscape 6" directory was created in that directory where the product resided. 2. Exit and remove the Branch build by removing the Netscape 6 directory. 3. Install the Trunk build in the same root directory. 4. When Profile Manager comes up, select an existing directory. Crash Talkback incident 24385069 cvt_s [prprf.c, line 373] dosprintf[prprf.c, line 975] PR_vsmprintf[prprf.c, line 1122] PR_vfprintf [prstdio.c, line 42] PR_fprintf[prstdio.c, line 35] CWellFormedDTD::HandleErrorToken [d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 737] CWellFormedDTD::HandleToken [d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 529] CWellFormedDTD::Terminate [d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 365] nsParser::Terminate [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1486] nsParser::Tokenize [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2450] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1887] nsParser::OnDataAvailable [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2337] RDFXMLDataSourceImpl::OnDataAvailable [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFXMLDataSource.cpp, line 1124] rdf_BlockingParse RDFXMLDataSourceImpl::Refresh [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFXMLDataSource.cpp, line 950] InternetSearchDataSource::GetCategoryList [d:\builds\seamonkey\mozilla\xpfe\components\search\src\nsInternetSearchService.cpp,line 1202] InternetSearchDataSource::DeferredInit [d:\builds\seamonkey\mozilla\xpfe\components\search\src\nsInternetSearchService.cpp, line 910] InternetSearchDataSource::Init [d:\builds\seamonkey\mozilla\xpfe\components\search\src\nsInternetSearchService.cpp, line 878] InternetSearchDataSourceConstructor [d:\builds\seamonkey\mozilla\xpfe\components\build\nsModule.cpp, line 46] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 48] nsComponentManagerImpl::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1202] nsComponentManager::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsRepository.cpp, line 82] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 345] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 492] nsServiceManager::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 605] RDFServiceImpl::GetDataSource [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFService.cpp, line 1172] nsXULDocument::CheckTemplateBuilder [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 5767] nsXULDocument::ResumeWalk [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 5076] nsXULDocument::OnStreamComplete [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 5436] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 123] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 703] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 302] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 101] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 577] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 513] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1055] KERNEL32.DLL + 0x248f7 (0xbff848f7) 0x00688b5a 0x00058f64
1/18 testing with 1/17 trunk build and limbo3, 2001010418Mtest build into same directory d:\seacurrent on my WinNT 4.0 sp3 TEST1 1. install trunk, launch 2. delete N6 directory 3. install limbo3 build into same directory 4. install completes, splash screen displays, crash No Profile Manager is seen (should be as many 4.x profiles exist on this machine) TEST2 1. install trunk build, run 2. install limbo3 build, choose 'delete old installation' option in install wizard 3. splash screen displays, crash-- No Profile Manager is seen TEST3 1. remove all profile data (registry/users50, c:\winnt\mozregistry.dat, mozver.dat) 2. install trunk build, run 3. delete N6/all profile data 4. install limbo3 build---crash after splash screen workaround is to install trunk/uninstall trunk and reinstall limbo3 build not sure what is going on behind scenes when splash screen is displayed - registering components? - that appears to cause crash.
Confirm on Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010119 Dr.Watson output snippet: Application exception occurred: App: mozilla.dbg (pid=247) When: 1/19/2001 @ 17:12:17.602 Exception number: c0000005 (access violation)
adding lchiang and selmer to cc list
From the talkback trace, this died while parsing the search service data src. Adding rjc to cc list. Robert, if it got as far as parsing I would assume that it found the file, right? If so, don't think this is profile mgr issue.
Adding a bunch of people to the CC to get traction on this. Is profiles in the clear? Anything related to install or registry keys? Robert is on sabbatical, anyone else familiar enough with search to help out?
Assignee: ccarlen → waterson
taking
I seem to be able to use the same profile between branch and trunk builds without any problem, so I don't think that is an issue.
I could not this following reporters instructions (modulo build dates): 1. Install 2001-01-22-13-MTEST into `c:\seacurrent' with xpinstaller. Build starts and runs fine. 2. Shutdown, blow away `c:\seacurrent\Netscape 6' directory. 3. Installed 2001-01-22-08-Mtrunk into `c:\seacurrent' with xpinstaller. Build starts and runs fine. Note that reporter indicates that the problem exists with the *trunk build*, not the branch build. Should this really be marked `critical'? (We've got `plenty of time' to fix the trunk build, right?)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Now, I'm not sure if this is the same bug or not, but... I'm on Win2K. I removed c:\winnt\mozregistry.dat, c:\winnt\mozver.dat, `c:\Documents and Settings\Chris Waterson\Application Data\Mozilla'. (I think that's everthing, right dveditz?) I have a 4.x install. I then re-downloaded 2001-01-22-13-MTEST from sweetlou. I now crash after install, during startup, with `necko.dll' and `chrome.dll' on the stack (no symbols, so I can't dig deeper).
Branch build just finished, here is a stack trace... nsString::GetUnicode() line 243 + 3 bytes nsProfile::MigrateAllProfiles(nsProfile * const 0x01ec0210) line 1956 + 11 bytes nsProfile::AutoMigrate() line 532 + 12 bytes nsProfile::ProcessArgs(nsICmdLineService * 0x01ebd1f0, int * 0x0012fc14, nsCString & {...}) line 752 nsProfile::StartupWithArgs(nsProfile * const 0x01ec0210, nsICmdLineService * 0x01ebd1f0) line 357 + 20 bytes InitializeProfileService(nsICmdLineService * 0x01ebd1f0) line 779 + 36 bytes main1(int 1, char * * 0x00454b80, nsISupports * 0x00000000) line 948 + 14 bytes main(int 1, char * * 0x00454b80) line 1171 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903() The crash I'm seeing is in the profile manager: gProfileDataAccess->mNumOldProfiles == 1 (presumably because I have on 4.x profile), but gProfileDataAccess->m4xProfiles->ElementAt(0) == nsnull
Whether this is the same thing as before, it's bad. Since it's in profile mgr, I'll take a look. This is the 20000922 branch?
Is it possible something corrupted their search rdf files and that's why you can't repro it? Any way to tell by looking at their rdf files?
Ok, re-opening. ccarlen: maybe a race condition: I'm getting tons of `threadsafe assertions' when running in a debug build (all trying to bring of the cursed activation window), but eventually it will start. No such luck with an optimized build, I crash trying to resolve a chrome URL (I think; again, no symbols). selmer: I doubt the issue has to do with search.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
So...to re-iterate. The key attributes (for me, anyway) seem to be: 1. `Clean' install; i.e., delete - mozregistry.dat - mozver.dat - profile directory (These will each get created over and over as you try to debug.) 2. Exactly one 4.x profile, so that automigration kicks in. 3. Netscape_20000922_BRANCH, `commercial' build. My results are intermittent: in a debug build, I saw one crash in the profile code (stack trace etc. above), but mostly now I'm just getting threadsafe assertions when opening one of the windows or dialogs that comes up while starting up. More random data. In a Netscape_20000922_BRANCH *Mozilla* build, I get an unskinned `Confirm Migration' dialog. Likewise, the `Converting Profile' dialog is unskinned. However, product starts up normally afterwards. Might this indicate that some initialization is happening out-of-order? cc'ing ben and hyatt.
Is this still the same bug then? Conrad traced the original problem to search. The "new" problem looks like it's directly in profile manager.
Chris, Did you also delete registry.dat under Application Data\Mozilla folder? That is the actual registry now.
The stack trace Chris provided looks to be clearly in the profile mgr. It looks to be totally diferent than the talkback trace posted earlier.
racham: yes, I removed the `Mozilla' folder altogether. selmer: just to be sure, I re-download the `big' SEA file for the MTEST bits, and I'm seeing the same crash. Here's a (relatively useless) stack trace, that shows we're down in Necko trying to resolve a chrome URL or something. Anyone know where we keep .map or .dbg files nowadays? NECKO! 015a92af() CHROME! 600f7be4() CHROME! 600f2379() XPCOM! 1002791a() XPCOM! 10029f30() XPCOM! 1002732f() XPCOM! 10027703() XPCOM! 10026e74() XPCOM! 100071c7() CHROME! 600f18c9() NECKO! 015abb19() DOCSHELL! 60119978() DOCSHELL! 60119612() DOCSHELL! 60118bdd() DOCSHELL! 601151b7() DOCSHELL! 60116f77() APPSHELL! 01126def() APPSHELL! 011260bf() APPSHELL! 01125f6a() NSPREFM! 60701591() PROFILE! 60723809() PROFILE! 60723d9b() PROFILE! 6072155f() NETSCP6! 0040250e() NETSCP6! 004015ef() NETSCP6! 004011b8() NETSCP6! 00402a47() KERNEL32! 77e87903()
Bhuvan and I tracked down how to reliably reproduce the bug. The steps look a lot like what esther originally reported, and our guess is that something is screwed up in the Windows registry. Here's what we did. 1. Start with a `clean' machine (i.e., no 6.x installed) 2. Install branch build into `c:\seacurrent' directory. It should start fine. 3. Delete `c:\seacurrent\Netscape 6' *by hand*. 4. Install trunk build int `c:\seacurrent' directory. This should start fine. 5. Delete `c:\seacurrent\Netscape 6' *by hand*. At this point, if you go into the `Add/Remove Programs' control panel, you'll see entries for both 6.0 and 6.01! 6. To reproduce crash, install branch build one more time. This *will not* start (saw a variety of stack traces). To recover system to normal state, 7. Use `Add/Remove Programs' to uninstall 6.0 build. (Even though 6.01 is what is really installed, it will process the uninstall log properly and clean out the windows registry.) 8. Now, if you try to uninstall 6.01 using `Add/Remove Programs', it won't do anything, because the uninstall log will have been blown away. 9. Re-install branch build. This should run fine now, and the windows registry's `installed program' state should match what's actually on the hard disk.
Assignee: waterson → ssu
Status: REOPENED → NEW
Component: Profile Manager BackEnd → Installer: XPInstall Engine
sean, this is probably not your fault, but somehow we get into a wedged state when you follow the above steps. Could you take a look? Seems like the installer could stop us from getting into this evil state (i.e., both `6.0' and `6.01' installed in same directory). It might be interesting to see if the crash happens if 6.0 and 6.01 are installed simultaneously in different directories... Anyway, give it back to me if there's nothing that can be done. I think we should downgrade this bug from `critical', as it requires some pretty arcane maneuvering to make it happen...
I'll take a look at it and see what I can come up with. Thanks for including the reproduceable steps.
Status: NEW → ASSIGNED
Sean, Chris, This was first noticed when installing a branch build in same directory as the daily trunk build - only later noticed that an installation of trunk over branch crashed too. Concern was that 6.01 will be installed in default C:\program files\netscape\netscape 6 over the 6.0 RTM install and crash. I tried that today and it does not crash.
Found the root of the problem. Just as the bug states, if you install a BRANCH build into the same directory as the previous TRUNK (not RTM) build, you get a crash at startup. This is because of PSM. Here's what's going on. For RTM and BRANCH, PSM is different from the current TRUNK builds. The BRANCH PSM contains its own version of xpcom files, while the TRUNK builds uses the browser's version of xpcom. So, walking thru the steps to reproduce the crash: 1) On a clean system, install a TRUNK build. This will install psm into the same folder as the browser (because that's where the version of xpcom it needs resides) 2) If you simply delete/rename the TRUNK installed folder out of the way, there is still a windows registry key set for PSM (the location of where it was last installed). If you install the BRANCH build at this point, the installer for it will attempt to locate where PSM was last installed (because we don't want duplicate copies of PSM). Since PSM was last installed in the same folder as the browser, it will do so *again*, but this time replacing the xpcom files with its own, thus crashing the browser at startup. As this bug points out, if the TRUNK build's Uninstaller was run first *prior* to installing the BRANCH build, the BRANCH build would work fine. This is because the PSM Windows registry keys would be removed, and would allow the BRANCH installer to install PSM (with it's own copy of xpcom files) into a default folder that is outside of the browser folder! The correct fix would be to do the following for the BRANCH build's installer: 1) At BRANCH build's install time, delete psm files from the user selected install path (regardless if they exist or not). 2) Detect if the old psm install path found (if one was found) matches the user selected install path. If so, then ignore it and use the default path that is *outside* the browser folder, which is [COMMON FILES]\Netscape Shared\Security. Looks like this bug should be moved to bugscape or at least marked confidential?
There might be another possible fix to this. Modify the TRUNK installer to *not* register where psm gets installed. We will then need to test to make sure of the following: * BRANCH installer will still install PSM to the default place. * TRUNK builds will be able to still locate PSM in the browser folder, in the case of PSM windows registry keys pointing elsewhere.
Or we could change the trunk so that it no longer registers or needs the PSM key to run, and no longer share a Mozilla-installed PSM. Since the Mozilla-installed PSM now shares files with that specific version of Mozilla, we do not want a different version Mozilla install to touch those files.
Sorry for saying the same thing, mid-air collision.
If we can change the trunk and not affect the branch, that would be ideal.
adding Bob and Javier to the CC: list to make sure PSM works as expected if the fix is applied to the TRUNK.
both Mozilla and Ns builds (TRUNK) no longer registers PSM in the windows registry. Reassigning to Javier to make sure that PSM still works when the Windows registry is not set.
Assignee: ssu → javi
Status: ASSIGNED → NEW
This solves part of the problem, a BRANCH build installed on top of a *future* TRUNK build. But anyone who installs a BRANCH build on top of an already-shipped mozilla0.7 or whatever will still have this problem. Is that good enough? Basically this can only truly be fixed in the BRANCH install script, perhaps by comparing the intended target (gotten from the registry or whatever) against getFolder("Program") and going to a fall-back target if they match. Don't know if anyone wants to take this kind of fix on the BRANCH at this point. I've had essentially the same problem going the other way, and this will completely screw over the SmartUpdate site unless we fix the BRANCH psm install script: 1) install 6.0 into directory A 2) install TRUNK build prior to ssu's fix into directory B 3) use SmartUpdate site/update.html to update BRANCH build Mostly the 6.0 build updates to the BRANCH, but PSM installs on top of the TRUNK build and kills it. The newly-installed BRANCH build works fine. Not sure what happens if the user then re-installs the TRUNK build--will the BRANCH be able to use the trunk version of PSM? (unlikely). I think we have to fix the BRANCH install script.
Dan, I think we're not going to have a conflict with Mozilla 0.6 or any versions of Mozilla that installs psm. This is because Mozilla's psm registered: HKLM\Software\[CompanyName]\Personal Security Manager\... where [CompanyName] is only either Mozilla or Mozilla.org. The RTM and current BRANCH builds search for Netscape as the company name. Here is the function from psm.xpi's install.js file that attempts to locate the destination of a previous PSM: function getPSMFolder() { var winReg = getWinRegistry(); if(winReg != null) { winReg.setRootKey(winReg.HKEY_LOCAL_MACHINE); subKey = "SOFTWARE\\Netscape\\Personal Security Manager\\Main"; valueName = "Install Directory"; fPSMstr = winReg.getValueString(subKey, valueName); if((fPSMstr == null) || (fPSMstr == "")) { subKey = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion"; valueName = "CommonFilesDir"; fCommonFilesDir = winReg.getValueString(subKey, valueName); fPSMstr = fCommonFilesDir + "\\Netscape Shared\\Security\\"; } fPSM = getFolder("file:///", fPSMstr); } else { logComment("getWinRegsitry() failed: " + winReg); } return fPSM; }
Assuming we're talking about PSM 1.4x here, then as long as the windows registry is set to where PSM was installed, this will all work fine. This version of PSM works fine with branch or trunk builds. If you don't want a trunk or branch build to replace a version of PSM a different build installed, then that I don't think we can do.
if((fPSMstr == null) || (fPSMstr == "")) if this is js, then you only need |if (!fPSMstr)|
Now that we've switched over to PSM 2, I don't think this bug is an issue anymore. If I'm wrong, please re-open bug.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → INVALID
vfy
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.