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

RESOLVED FIXED in seamonkey2.1a2

Status

SeaMonkey
Installer
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: therube, Assigned: Robert Kaiser)

Tracking

({fixed-seamonkey2.0.6})

Trunk
seamonkey2.1a2
x86
Windows XP
fixed-seamonkey2.0.6

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Created attachment 441825 [details]
compreg.dat from SeaMonkey 2.0.4

My existing 2.0.4 version of compreg.dat.
(Reporter)

Comment 2

7 years ago
Created attachment 441826 [details]
compreg.dat from SeaMonkey 2.1a

compreg.dat from SeaMonkey 2.1a for comparison.
(Reporter)

Comment 3

7 years ago
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.
Component: General → Startup & Profiles
QA Contact: general → profile-manager
Version: unspecified → Trunk
(Assignee)

Comment 5

7 years ago
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.
Assignee: nobody → installer
Component: Startup & Profiles → Installer
QA Contact: profile-manager → xpi-packages
(Reporter)

Comment 6

7 years ago
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.
(Reporter)

Comment 7

7 years ago
"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.
(Assignee)

Comment 8

7 years ago
Hmm, I didn't know that we're still creating them in the application directory. We actually shouldn't do that...
(Reporter)

Comment 9

7 years ago
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
(Assignee)

Comment 10

7 years ago
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.
(Assignee)

Comment 12

7 years ago
(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?
(Reporter)

Comment 13

7 years ago
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.
(Reporter)

Comment 14

7 years ago
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.)
(Reporter)

Comment 15

7 years ago
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

7 years ago
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
(Reporter)

Comment 17

7 years ago
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.
(Assignee)

Comment 18

7 years ago
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.
Assignee: installer → kairo
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #445550 - Flags: review?(bugspam.Callek)

Updated

7 years ago
Attachment #445550 - Flags: review?(bugspam.Callek) → review+
(Assignee)

Comment 19

7 years ago
Pushed as http://hg.mozilla.org/comm-central/rev/b194818d3521 - I hope this is fixed for trunk builds with that.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.1a2
(Assignee)

Updated

7 years ago
Attachment #445550 - Flags: approval-seamonkey2.0.6?

Updated

7 years ago
Attachment #445550 - Flags: approval-seamonkey2.0.6? → approval-seamonkey2.0.6+
(Assignee)

Comment 20

7 years ago
Pushed on 1.9.1 as http://hg.mozilla.org/releases/comm-1.9.1/rev/8bf70dc833c5
(Assignee)

Updated

7 years ago
Keywords: fixed-seamonkey2.0.6
You need to log in before you can comment on or make changes to this bug.