If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

installer fails to complete (error type 1)



16 years ago
3 years ago


(Reporter: tracy, Assigned: Syd Logan)



Mac System 9.x

Firefox Tracking Flags

(Not tracked)



(2 attachments)



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


16 years ago
Keywords: smoketest


16 years ago
QA Contact: bugzilla → ktrina

Comment 1

16 years ago
Could this be related to tao's checkin for bug 72496 which was mac specific?


Comment 2

16 years ago
Did this happen to 2001-10-17's trunk build? That patch was checked in on Oct 16.

Comment 3

16 years ago
Full installer or stub installer?

Comment 4

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

Comment 5

16 years ago
I checked with Tracy and it didn't happen with yesterday build.  Loan

Comment 6

16 years ago
Simon, both installers fail.

Comment 7

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

16 years ago
It looks to me like XPI_Init() is failing because 
nsComponentManager::AutoRegister() fails. cc'ing folks who touched XPCOM 

Comment 9

16 years ago
does this only happen on mac?  Simon, where in nsComponentManager::AutoRegister
() does it fail?

Comment 10

16 years ago
Yep, Mac only.

Comment 11

16 years ago
dougt: I was not able to debug into this (opt build, no .xSYM files etc).

Comment 12

16 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?  
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? :)


dont know if that adds to this issue.. or if it just another network glitch that
happened while I tried.

Comment 15

16 years ago
Debugging the Mac installer:

Comment 16

16 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

16 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

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

16 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

16 years ago
The linux installer creates a components directory.  I believe windows does too
but will defer to Sean on that.

Comment 21

16 years ago
yep.  the windows installer does create a components folder.  it's actually part 
of xpcom.xpi for the windows platform.

Comment 22

16 years ago
Ah. I'm thinking that we should fix the Mac installer.

Comment 23

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

Comment 25

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


Comment 26

16 years ago
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:
and bug 23389, bug 36784.

Comment 27

16 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

16 years ago
Created attachment 54139 [details] [diff] [review]
proposed (temporary!) workaround patch

Comment 29

16 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

16 years ago
Created attachment 54147 [details] [diff] [review]
Working patch

Comment 31

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

Comment 32

16 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: 
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

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

Comment 34

16 years ago
Fix checked in. Thanks. 
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 35

16 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 

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

Comment 36

16 years ago
I filed bug 105569 on the mac installer

Comment 37

16 years ago
verified fixed on mac commercial build 2001-10-22-04-trunk
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.