Closed
Bug 105437
Opened 23 years ago
Closed 23 years ago
installer fails to complete (error type 1)
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: tracy, Assigned: slogan)
Details
(Keywords: smoketest)
Attachments
(2 files)
731 bytes,
patch
|
Details | Diff | Splinter Review | |
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.
Updated•23 years ago
|
QA Contact: bugzilla → ktrina
Could this be related to tao's checkin for bug 72496 which was mac specific? http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=&subdir=mozilla/xpinstall/packager&command=DIFF_FRAMESET&root=&file=packages-mac&rev1=1.143&rev2=1.144
Did this happen to 2001-10-17's trunk build? That patch was checked in on Oct 16.
Comment 3•23 years ago
|
||
Full installer or stub installer?
Comment 4•23 years ago
|
||
Just to clarify, the installer is not crashing. It's putting up a dialog that says "the installation failed because of an error -1".
Reporter | ||
Comment 6•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
It looks to me like XPI_Init() is failing because nsComponentManager::AutoRegister() fails. cc'ing folks who touched XPCOM yesterday.
Comment 9•23 years ago
|
||
does this only happen on mac? Simon, where in nsComponentManager::AutoRegister () does it fail?
Reporter | ||
Comment 10•23 years ago
|
||
Yep, Mac only.
Comment 11•23 years ago
|
||
dougt: I was not able to debug into this (opt build, no .xSYM files etc).
Comment 12•23 years ago
|
||
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?
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
Debugging the Mac installer: <http://www.mozilla.org/projects/xpinstall/wizard/mac/debugging.html>
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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)
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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?
Comment 20•23 years ago
|
||
The linux installer creates a components directory. I believe windows does too but will defer to Sean on that.
Comment 21•23 years ago
|
||
yep. the windows installer does create a components folder. it's actually part of xpcom.xpi for the windows platform.
Comment 22•23 years ago
|
||
Ah. I'm thinking that we should fix the Mac installer.
Comment 23•23 years ago
|
||
The mac xpcom.xpi contains the directories too, but its unzipped flattened. Why?
Comment 24•23 years ago
|
||
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?
Comment 25•23 years ago
|
||
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
Comment 26•23 years ago
|
||
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.
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
jband: this patch does not work. It's BuildFileList() that fails, not BuildFileSearchPath(). The failure happens at: rv = dir->GetDirectoryEntries(getter_AddRefs(entries));
Comment 30•23 years ago
|
||
Comment 31•23 years ago
|
||
jband, please look at the last patch. It returns NS_OK if we BuildFileList fails.
Comment 32•23 years ago
|
||
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;
Comment 33•23 years ago
|
||
Looks good to me, r/sr=sfraser. jband, can you check that in?
Comment 34•23 years ago
|
||
Fix checked in. Thanks.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 35•23 years ago
|
||
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?
Comment 36•23 years ago
|
||
I filed bug 105569 on the mac installer
Reporter | ||
Comment 37•23 years ago
|
||
verified fixed on mac commercial build 2001-10-22-04-trunk
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•