Installer crashes the machine at the end of installation

VERIFIED WORKSFORME

Status

SeaMonkey
Installer
--
critical
VERIFIED WORKSFORME
17 years ago
13 years ago

People

(Reporter: Simon Fraser, Assigned: Samir Gehani)

Tracking

Trunk
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
I just ran the Mozilla full installer, at 
<ftp://sweetlou/products/client/6.0x/macos/8.x/ppc/2001-04-16-04-trunk/
MacMozillaFullInstaller.sea.bin>

and it crashed at the end of the installation process. Mozilla seems to be fully 
installed; there is an alias on the desktop. However, there is no Component 
registery file. The log (to be attached) shows that we had reached the point 
where xpinstall, xpcom etc were loaded.
(Reporter)

Comment 1

17 years ago
Critical; installation crashes are deadly serious.
Severity: normal → critical
(Reporter)

Comment 2

17 years ago
Created attachment 31065 [details]
stdlog for the crash.
(Reporter)

Comment 3

17 years ago
The log doesn't show much useful info. Snippets:

  Current application is “Mozilla Installer”
 The target heap is the “Mozilla Installer” heap at 08CC7FD0
 Totaling the “Mozilla Installer” heap at 08CC7FD0
                                 Total Blocks    Total of Block Sizes
  Free                           0017      #23   003A5D20     #3824928 (#3735K)
  Nonrelocatable                 00DC     #220   0044E17C     #4514172 (#4408K)
  Relocatable                    00AE     #174   00015830       #88112 (#86K)
    Locked                       0001       #1   000006C0        #1728
    Purgeable and not locked     0014      #20   00000670        #1648
  Heap size                      01A1     #417   008096CC     #8427212 (#8229K)
  #384 FCBs, #231 in use (including #74 fonts not listed), #153 free

No useful stack. No heaps were corrupted.
Summary: Installer crashes at the end of installation → Installer crashes the machine at the end of installation
Is this perhaps the running-out-of-resources-while-autoreg-ing crash? Why 
are we still not shipping one?
(Reporter)

Comment 5

17 years ago
The FCB count doesn't appear to indicate that we ran out of open files. It's not 
near a boundary, and the machine was running for 6 hours before this.
(Reporter)

Comment 6

17 years ago
Created attachment 31078 [details]
Spotlight debug log for the installer
(Reporter)

Comment 7

17 years ago
That spotlight log shows up some other problems, but nothing that might have 
caused this crash.
(Reporter)

Comment 8

17 years ago
Should I get a Component Registry using this installer, because I'm not seeing 
one, even after an apparently successful install.
(Reporter)

Comment 9

17 years ago
There is some weirdness here. During installation, in the folder {temp 
items}:Temp NSInstall is a folder called "intstall.jsponents" which contains a 
text file "xpinstall.shlblb.shlb". this file contains some JS code.
This looks to me like bad string termination, which would rely on uninitialized 
memory.
(Reporter)

Comment 10

17 years ago
Fix for the bad file names:

Index: mozilla/xpinstall/wizard/mac/src/Deflation.c
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/wizard/mac/src/Deflation.c,v
retrieving revision 1.21
diff -u -2 -r1.21 Deflation.c
--- Deflation.c	2000/08/16 22:43:08	1.21
+++ Deflation.c	2001/04/17 01:55:07
@@ -222,5 +222,5 @@
 			return err;
 
-        strncpy(macfilename, filename, strlen(filename));
+        strcpy(macfilename, filename);
         SLASHES_2_COLONS(macfilename);
 		HLock(fullPathH);


Fix for the Spotlight warning:

Index: mozilla/xpinstall/wizard/mac/src/LicenseWin.c
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/wizard/mac/src/LicenseWin.c,v
retrieving revision 1.12
diff -u -2 -r1.12 LicenseWin.c
--- LicenseWin.c	2001/03/28 00:42:19	1.12
+++ LicenseWin.c	2001/04/17 01:55:18
@@ -193,4 +193,5 @@
 			{
 			    RGBColor backColorOld;
+			    Rect     textRect;
 			    
 			    // get back color
@@ -201,6 +202,7 @@
 			    
 			    // erase rect and update
-			    EraseRect(&(**(gControls->lw->licTxt)).viewRect);
-				TEUpdate( &(**(gControls->lw->licTxt)).viewRect, gControls->
lw->licTxt);
+			    textRect = (**(gControls->lw->licTxt)).viewRect;
+			    EraseRect(&textRect);
+				TEUpdate( &textRect, gControls->lw->licTxt);
 				
 				// restore back color
(Reporter)

Comment 11

17 years ago
sr=sfraser on both patches. I think they are fine!

Comment 12

17 years ago
r=ssu for both files being patched.
(Assignee)

Comment 13

17 years ago
Simon's patch checked in.  Thanks for the Spotlight warnings patch Simon!


Simon reports he could not repeat this.

In response to Simon's 2001-04-16 18:31 comment: 
> Should I get a Component Registry using this installer, because I'm not seeing 
> one, even after an apparently successful install.

After a successful install mozilla should have launched so the post-install 
generated Component Registry should exist.  The mozilla packages-mac manifest 
indicates we are trying to ship a pre-generated Component Registry although 
poking a browser.xpi from this morning's build reveals no Component Registry 
file.  Not sure if this is a build glitch or generation of the Component 
Registry hasbeen turned of (possibly due to resurfacing of regxpcom 
instability).  JJ is in a better position to comment on the latter.
Status: NEW → ASSIGNED

Updated

17 years ago
QA Contact: gemal → gbush

Comment 14

17 years ago
JJ is out of town until 5/1, who's covering packaging issues in his absence?
the installer does not launch mozilla. only the commercial installer launches the 
product. in fact, i don't think the commercial installer should do this at all 
(but that's another bug).

we should be shipping a pre-installed component reg or build it into the 
installer -- not relying on auto-launching to get one. loading in all the 
components sucks up huge amounts of ram and we'll run out of memory quickly 
during this first run. A woeful first impression indeed!

Comment 16

17 years ago
re: pre-built Component Registry issue discussed above:
> Not sure if this is a build glitch or generation of the Component 
> Registry hasbeen turned of (possibly due to resurfacing of regxpcom 
> instability).  JJ is in a better position to comment on the latter.

Good guess. auto reg has actually been turned off after several attemps so there 
is currently no Component Registry packaged in the installer (again). Recent 
attempts to launch the app (moz or ns6) at the end of the build resulted in 
crashes. I have 2 -different- stack traces from 05/30 that I will attach to bug 
#46000 which is addressing this particular issue. Discussion/investigations on 
the autoreg problems should continue there rather than here.

Comment 17

17 years ago
bug 46000 has been resolved/verified,
markingthis  worksforme, not seeing crashes on Mac installs in long time

please reopen if this recurs
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 18

17 years ago
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.