Closed Bug 105437 Opened 23 years ago Closed 23 years ago

installer fails to complete (error type 1)

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
PowerPC
Mac System 9.x
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tracy, Assigned: slogan)

Details

(Keywords: smoketest)

Attachments

(2 files)

proposed (temporary!) workaround patch
731 bytes, patch
Details | Diff | Splinter Review
Working patch
998 bytes, patch
Details | Diff | Splinter Review 
seen on mac commercial trunk build 2001-10-18-04-trunk

-attempt to install with either installer (full or stub)

a few moments into the install the process halts with an error type 1.
Keywords: smoketest
QA Contact: bugzilla → ktrina
Did this happen to 2001-10-17's trunk build? That patch was checked in on Oct 16.
Full installer or stub installer?

Just to clarify, the installer is not crashing. It's putting up a dialog that 
says "the installation failed because of an error -1".

I checked with Tracy and it didn't happen with yesterday build.  Loan
Simon, both installers fail.
Just verified that 2001-10-17's trunk build is fine and all three
en-{unix,mac,win}.jar are installed as expected.
It looks to me like XPI_Init() is failing because 
nsComponentManager::AutoRegister() fails. cc'ing folks who touched XPCOM 
yesterday.

does this only happen on mac?  Simon, where in nsComponentManager::AutoRegister
() does it fail?
Yep, Mac only.
dougt: I was not able to debug into this (opt build, no .xSYM files etc).

are there instructions on how to build/test the mac installer?  Can someone try
backing out jband or my changes and rebuilding?

samir, can you lend a hand?  
I couldn't get the installer to even download on windows after I had tried to
restart it (on 2001-10-17 build latest nightly yesterday), after I had canceled
it cuz I didn't want to download at a slow dialup connection at 31K, I wanted to
reconnect at 49K so it would go faster.  So I ended up downloading the .zip
version and installing that one.
Just to note:

I didn't get that error message at all.. I just got the network couldn't get it
to connect so I can download.  Maybe server was taking a break when I tried? :)

dennis

dont know if that adds to this issue.. or if it just another network glitch that
happened while I tried.
So does anyone have a new Mac debug build that we can experiment with? This 
could certainly be caused by my typelib loader changes. But I have no way to 
debug it.
When I launch the Debugger with the Installer, I am seeing an error when it tries 
to open "installer.ini" (in xpinstall/wizard/mac/src/Parser.c)

Doug,
If autoreg is failing then it may be possible to test using a small app that
mimics what XPI_Init() does in xpistub.cpp rather than the cumbersone installer
setup one has to go through to debug.  If the app is autoreg'ing fine but the
installer is not then one difference is that we are only autoreg'ing 3
components: so one would have to debug using the installer (or the small app
that mimics XPI_Init()).

Another possible idea: if there were any linkage changes for xpinstall.shlb,
libjar.shlb, or unicharutil.shlb (the 3 components included in xpcom.xpi which
are extracted at install time for the XPInstall engine to run) then they may
fail to load.  See:
<http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/packages-mac#35> for
the list of libs extracted at install-time.
kin and I debugged on the build machine, and here's what we found:
The installer unzips xpcom.xpi, put the results flat in a temporary 'viewer' 
directory. It then calls NS_InitXPCOM2. This returns an error, which propagates 
up from the xpt interface code (which failed because it failed to find the 
"Components" directory).

So my guess is that what changed is that jband's changes made xpt registration 
code return errors if it failed to find the Components folder. I also guess that 
this only fails on Mac because of the way the installer works -- does the windows 
installer create a 'components' folder when it unstuffs xpcom.xpi?

The linux installer creates a components directory.  I believe windows does too
but will defer to Sean on that.
yep.  the windows installer does create a components folder.  it's actually part 
of xpcom.xpi for the windows platform.
Ah. I'm thinking that we should fix the Mac installer.
The mac xpcom.xpi contains the directories too, but its unzipped flattened. Why?

The Mac installer uses the documented method of specifying a non-default
components directory. If you have broken the mac installer you've likely broken
the other folks who broke us when they changed it. I'm not sure who the other
clients of this were, maybe blackwood?
Hmm. Then this might be seen as a bug in nsDirectoryService. xpti does not care 
where the components directory is, it just tries to get the nsILocalFile for 
it from nsDirectoryService. The serivce makes the assumptions aout it being a 
subdir of the appdir...

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryService.cpp#739
Simon,
I believe the directories were flattened to get around some lib loading issues
(finding essential files' shlbs that components shlbs were linked to).  Also see
rev 1.14 and 1.18 log comments for Defaltions.c:
<http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpinstall/wizard/mac/src/Deflation.c>
and bug 23389, bug 36784.
Unless someone comes up with something better, I can make xpti startup *not* 
fail if it can't find the components dir. I'm testing a patch to see if it will 
generally fail gracefully. This is still pretty whacky though.
jband: this patch does not work. It's BuildFileList() that fails, not 
BuildFileSearchPath(). The failure happens at:

        rv = dir->GetDirectoryEntries(getter_AddRefs(entries));

jband, please look at the last patch. It returns NS_OK if we BuildFileList fails.

Ah right. The nsDirectoryService gives me the nsILocalFile for the directory 
even though it does not exist. So the search path is not empty.

You can check in a quick hack to get the tree open if you want. I like the 
following a little better though...

Index: xptiInterfaceInfoManager.cpp
===================================================================
RCS file: 
/cvsroot/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp,v
retrieving revision 1.23
diff -u -r1.23 xptiInterfaceInfoManager.cpp
--- xptiInterfaceInfoManager.cpp	2001/10/18 04:23:24	1.23
+++ xptiInterfaceInfoManager.cpp	2001/10/19 00:09:52
@@ -289,7 +289,7 @@
         nsCOMPtr<nsISimpleEnumerator> entries;
         rv = dir->GetDirectoryEntries(getter_AddRefs(entries));
         if(NS_FAILED(rv) || !entries)
-            return PR_FALSE;
+            continue;
 
         PRUint32 count = 0;
         PRBool hasMore;

Looks good to me, r/sr=sfraser. jband, can you check that in?

Fix checked in. Thanks.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I filed bug 105568 on the issue of what nsDirectoryService ought to return when 
asked for the components directory when NS_InitXPCOM2 was passed a specific 
directory.

Does anyone want to file another bug on the Mac installer not doing this 
flattening, or just leave it as is?

I filed bug 105569 on the mac installer

verified fixed on mac commercial build 2001-10-22-04-trunk
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Depends on: 1054349
No longer depends on: 1054349
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: