User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20100317 SeaMonkey/2.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100317 SeaMonkey/2.0.4
Installing SeaMonkey Trunk 2.1a build overtop an existing (installed) SeaMonkey 2.0.4 (Branch release) cause SeaMonkey to be non-functional.
Steps to Reproduce:
1. Download SeaMonkey 2.0.4 release installer & install (SeaMonkey Setup 2.0.4.exe)
2. Download a SeaMonkey comm-central-trunk build & install overtop (into) the same directory that SeaMonkey 2.0.4 was installed into (seamonkey-2.1a1pre.en-US.win32.installer.exe)
3. Run SeaMonkey
By this point, the installer process has completed.
The SeaMonkey process starts, my firewall notes the attempt to access the Internet.
SeaMonkey GUI fails to load, & SeaMonkey has exited (as a Process) from memory.
SeaMonkey should install & run as expected.
On installation, SeaMonkey 2.1a does not overwrite the existing SeaMonkey 2.0 files; components/compreg.dat & components/xpti.dat.
On the 1st startup attempt, xpti.dat is modified. compreg.dat remains unchanged.
SeaMonkey fail to load. No GUI displays. seamonkey.exe is not a Process in (Windows) Task Manager.
If you delete xpti.dat & compreg.dat, SeaMonkey will then load & run as expected.
After deleting (xpti.dat & compreg.dat), the (again) newly created xpti.dat file is identical to the version that was (recreated) on the 1st run attempt. The compreg.dat file is (now) extensively changed.
Appears that the failure to delete (on install) compreg.dat, or for compreg.dat to recreated itself (on first run) is at fault.
In other instances I have observed crashes caused by this.
Created attachment 441825 [details]
compreg.dat from SeaMonkey 2.0.4
My existing 2.0.4 version of compreg.dat.
Created attachment 441826 [details]
compreg.dat from SeaMonkey 2.1a
compreg.dat from SeaMonkey 2.1a for comparison.
Created attachment 441827 [details]
A tracking of the install of SeaMonkey 2.1a1.
Note that neither xpti.dat nor compreg.dat are noted in the listing as neither were modified during the install.
I'm not resolving this INVALID yet, because I want a second opinion; but installing a new version straight on top of another one which is not its immediate predecessor, without uninstalling the other version first, has always been known to be courting disaster. The Windows installer may be a special case though.
Actually, this should work in theory, the installer should clean up files that cause a problem.
For now, I'll move this to the installer, but not sure yet if the problem actually lies there.
Can you please tell where those compreg.dat and xpti.dat files are located? Inside the application folder or inside the profile folder? They should only exist in the latter, and we should detect at startup that they are out of date and replace them, esp. if they're in the profile. In that latter case, if that mechanism doesn't work, that's not an installer problem but one in the Core code that should care about this.
Didn't even realize that.
From the looks of it both xpti.dat & compreg.dat reside in both the application folder & also in the Profile folder.
In this case, it is the application folder (I'm assuming) where the problem lies, as ... maybe that's a wrong assumption ...?
If you extract a ZIP version of 1.1.19, run seamonkey.exe, copies of xpti.dat & compreg.dat are newly created in the Application folder. So SeaMonkey 1.1.x is doing that.
Appears that a SeaMonkey 1.1.x Profile does not contain either xpti.dat or compreg.dat.
If you extract a ZIP version of 2.0.4, run seamonkey.exe, copies of xpti.dat & compreg.dat are newly created in the Application folder. So SeaMonkey 2.0.x is doing that.
Additionally SeaMonkey 2.0.4 also creates copies of xpti.dat & compreg.dat in the Profile folder. (If they files were not pre-existing in the Profile folder, the newly created files look to be slightly revised compared to the versions found in Application folder. Revised like; chatzilla & venkman & inspector references are newly added - among other changes. Also these newly created Profile copies are not created until after the Profile has been chosen <in Profile Manager>.)
My comments on 2.0.4 also pertain to 2.1a. First copies of the files are newly created in the Application folder, then once the Profile is chosen, they are also newly created there too. And in the same way, the Profile copies are slightly revised compared to the Application copies.
Compared with 2.0.x the 2.1a versions are extensively changed.
In Comment #1 I mentioned /If you delete xpti.dat & compreg.dat, SeaMonkey will then load & run as expected./, I was speaking of the versions in the (/components/ directory in the) Application folder. (Hadn't realized at the time that they <could> exist elsewhere.)
Per Comment #1, the Application folder 2.0 versions are not being recreated (deleted, written) by the 2.1a versions.
Wouldn't know how the Profile folder varieties might or might not affect things, though 2.1a does run successfully with a 2.0 Profile.
"My comments on 2.0.4 also pertain to 2.1a." -- when installed into a new directory.
"Per Comment #1, the Application folder 2.0 versions are not being recreated
(deleted, written) by the 2.1a versions." -- when installed overtop an existing SeaMonkey 2.0.x installation.
Hmm, I didn't know that we're still creating them in the application directory. We actually shouldn't do that...
Probably worthless crash reports, but ...
Crash report are probably not too helpful there, yes, we already know that it's the compreg.dat that causes the problems.
Now, I wonder why you see SeaMonkey 2.0.x even creating a compreg.dat in the application directory, we shouldn't do that, AFAIK. And then, trunk trying to just use it is probably a bug as well.
Benjamin, do you have any idea as to why that happens?
Note that I'd suspect that Firefox trunk over 3.5.x probably runs into the same problem, as it's the same core code/XPCOM that cares about this, after all.
The compreg in the appdir is used when we show the profile manager.
(In reply to comment #11)
> The compreg in the appdir is used when we show the profile manager.
Interesting - and we don't re-create it automatically when it's outdated, like we do for the one in the profile directory?
If so, should we add it to removed-files so it gets wiped on any updates or re-installs?
Just to point out, in all likelihood, going the other direction - overwriting a 2.1a install with a 2.0.x install, while it appears the 2.0.x install will work, there are still anomalies.
Like I noticed that I was not able to drag an .xpi into the browser window. (Though I could drag it into the Add-ons window. Wonder what would happen with an about:addons window ;-) ?)
Again this looks related to compreg.dat in the Application /components/ folder.
Another (perhaps) related situation ...
I have two user logins in XP.
Was running SeaMonkey under 1. At some point, I exited SeaMonkey, logged out of 1, & logged into 2.
While logged into 2, & over the course of browsing, I restarted SeaMonkey a few times. One of those times installed an updated. All was well. Finished up what I was doing under user 2.
Logged out of 2 & back into 1.
Started SeaMonkey & (unexpectedly) it crashed before it got to the Profile Manager dialog. (Didn't look at the crash report as I suppose it is again worthless?) Tried starting again with the same results.
Kind of knew what the problem was. So I renamed (the Application folder) /components/compreg.dat (& xpti.dat). SeaMonkey recreated both & started up just fine.
Now did a change made during the update cause this (presumably compreg.dat to become invalid)? (Suppose I could rename the particular compreg.dat back & try loading SeaMonkey under user 2 & see what gives?) Or might this simply have been some partially valid compreg.dat file that did not cause an immediate failure?
(Also note that I am working on two different systems, & while I have seen this on both, some things I have noted occurred on one & not necessarily the other. One system I have continued to run SM 2.1a & on the other I have reverted back to 2.0.4.)
Ah, there is crash data this time. Pays to look :-).
Signature nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**)
Time 2010-04-30 05:07:56.944272
Last Crash 652847 seconds before submission
Build ID 20100429124807
OS Windows NT
OS Version 5.1.2600 Service Pack 3
CPU Info GenuineIntel family 6 model 15 stepping 2
Crash Reason EXCEPTION_ACCESS_VIOLATION
Crash Address 0x0
* Bug 530447 NEW startup crash [@ nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**)]
* Bug 530845 NEW crash [@ nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**)] (not startup)
Frame Module Signature [Expand] Source
0 seamonkey.exe nsWindowWatcher::OpenWindowJSInternal embedding/components/windowwatcher/src/nsWindowWatcher.cpp:523
1 seamonkey.exe nsWindowWatcher::OpenWindow embedding/components/windowwatcher/src/nsWindowWatcher.cpp:423
2 seamonkey.exe ShowProfileManager toolkit/xre/nsAppRunner.cpp:1971
3 seamonkey.exe SelectProfile toolkit/xre/nsAppRunner.cpp:2310
4 seamonkey.exe XRE_main toolkit/xre/nsAppRunner.cpp:3236
5 seamonkey.exe NS_internal_main suite/app/nsSuiteApp.cpp:103
6 seamonkey.exe wmain toolkit/xre/nsWindowsWMain.cpp:120
7 seamonkey.exe __tmainCRTStartup objdir/mozilla/memory/jemalloc/crtsrc/crtexe.c:591
8 kernel32.dll BaseProcessStart
So I had a crash today:
Look at my comments:
I'm betting: Bug 562047 (not 546356, dumy!) ... I had installed a 2.1a2 nightly (via Check for Updates...). Addons Manager was again broken, so I downloaded the (last?) 2.1a1 nightly (5-10-10) & installed that overtop (into the same directory). Before installing, I particularly made note of the compreg.dat & xpti.dat files in the /components/ directory, & they remained unchanged after install (of 2.1a1). Betchya that once I delete those two files
Note: I referenced the WRONG bug in my crash comments. I meant to reference this one (~:
Anyhow, I won my bet.
Created attachment 445550 [details] [diff] [review]
remove compreg.dat/xpi.dat on every update/install
From what has been reported here, this patch should fix that case by removing compreg.dat/xpti.dat on every update/install.
I also noticed that a comment has somehow made its way to a wrong place and am correcting this in this patch as well.
Pushed as http://hg.mozilla.org/comm-central/rev/b194818d3521 - I hope this is fixed for trunk builds with that.
Pushed on 1.9.1 as http://hg.mozilla.org/releases/comm-1.9.1/rev/8bf70dc833c5