562047 - Installing Trunk 2.1a Overtop Existing Branch 2.0 Causes Non-Functional SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Installer, defect)

Description

[therube]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) 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.
 

Reproducible: Always

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
 
Actual Results:  
 
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.
 

Expected Results:  
 
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.

Comment 1

[therube]

Attachment: compreg.dat from SeaMonkey 2.0.4

My existing 2.0.4 version of compreg.dat.

Comment 2

[therube]

Attachment: compreg.dat from SeaMonkey 2.1a

compreg.dat from SeaMonkey 2.1a for comparison.

Comment 3

[therube]

Attachment: 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.

Comment 4

[Tony Mechelynck [:tonymec]]

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.

Comment 5

[Robert Kaiser]

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.

Comment 6

[therube]

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.

Comment 7

[therube]

"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.

Comment 8

[Robert Kaiser]

Hmm, I didn't know that we're still creating them in the application directory. We actually shouldn't do that...

Comment 9

[therube]

Probably worthless crash reports, but ...

http://crash-stats.mozilla.com/report/index/bp-109c0ecf-700f-4d60-a27e-e27c82100421

http://crash-stats.mozilla.com/report/index/bp-388a766f-85bd-44cb-aa09-e69aa2100422

Comment 10

[Robert Kaiser]

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.

Comment 11

[Benjamin Smedberg]

The compreg in the appdir is used when we show the profile manager.

Comment 12

[Robert Kaiser]

(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?

Comment 13

[therube]

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.

Comment 14

[therube]

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.)

Comment 15

[therube]

Ah, there is crash data this time.  Pays to look :-).

http://crash-stats.mozilla.com/report/index/bp-46f3fbf7-5ca6-48fb-9bbf-c18f22100430

http://crash-stats.mozilla.com/report/index/bp-b95339c1-8a7d-4ead-a3cb-0d3e22100430

Comment 16

[timeless]

Signature	nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**)
UUID	46f3fbf7-5ca6-48fb-9bbf-c18f22100430
Time 	2010-04-30 05:07:56.944272
Uptime	1
Last Crash	652847 seconds before submission
Product	SeaMonkey
Version	2.1a1pre
Build ID	20100429124807
Branch	1.9.3
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	
Related Bugs

        * 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)

Crashing Thread
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

Comment 17

[therube]

So I had a crash today:
http://crash-stats.mozilla.com/report/index/bp-db291305-1f0e-4fbf-84ae-a62b82100512

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.

Comment 18

[Robert Kaiser]

Attachment: 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.

Comment 19

[Robert Kaiser]

Pushed as http://hg.mozilla.org/comm-central/rev/b194818d3521 - I hope this is fixed for trunk builds with that.

Comment 20

[Robert Kaiser]

Pushed on 1.9.1 as http://hg.mozilla.org/releases/comm-1.9.1/rev/8bf70dc833c5