72636 - Linux installer fails to install modules

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P2)

Description

[Ric Johnson]

For the last 2 builds 20010318 and 19, I have been lazy. ;)
I did not manually delete /usr/local/mozilla and, instead, let installer do that
for me.  Well, it said it would; don't know if it actually did.

I do not know if that is the cause but yesterday at the end of the install, the
messages "installation complete" and "-621 An installer module (.xpi) failed to
install" have been displayed. Same message, both days.

Yesterday, it appeared that the module that failed to install was the
talkback(QA) since there were no pop-ups when moz crashed.  

Today, it appears that it is actually the xpi installer module that failed to
install because every time I attempt to install a xpi module the dialog window
appears '...install a module' and as soon as I click 'OK', moz crashes.

This has not happened before.  The messages and what not might need a little
polish, but the installer has worked very good to get moz installed and running
every other time I used it.

I'm gonna try to not be lazy and see if the installer works this time.


Ric

Comment 1

[Sean Su]

sending over to samir.

Comment 2

[Ric Johnson]

Ok, I deleted the /usr/local/mozilla directory contents and the Installer began
as normal and installed Linux 2001031921 build.

Xpi install still segfaults so it's probably _not_ because the directory was
there at the beginning of the install and, for that matter, probably not even
the installer at fault... dunno; many other parts are broken in this 1921 build. 

However, the Xpi install is definitely broken here as well as: moz is crashing
on 'apply theme', 'save' download,...others,  close mail (caught that one):
mailbox://[e-mail]
In ChangeFolderByURI uri = mailbox://[e-mail]

OnUnload from XUL
Clean up ...
/usr/local/mozilla/run-mozilla.sh: line 72:  3172 Segmentation fault      $prog
${1+"$@"}
----------

It doesn't seem to matter if the 'ok' or the 'cancel' is selected, it still
segfults.  Talkback is not working so I can't give much more than what's below.

Repeatable everytime 'OK' or 'Cancel' is selected in the XPI Install dialog window. 

Here's the output from the console during the install and the result of trying
to install a xpi(which, btw, worked just fine many times before on builds
previous to 18) after I selected OK:

/usr/local/mozilla/run-mozilla.sh /usr/local/mozilla/mozilla-bin -installer
MOZILLA_FIVE_HOME=/usr/local/mozilla
LD_LIBRARY_PATH=/usr/local/mozilla:.:.:
LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/components
SHLIB_PATH=/usr/local/mozilla
LIBPATH=/usr/local/mozilla
ADDON_PATH=/usr/local/mozilla
MOZ_PROGRAM=/usr/local/mozilla/mozilla-bin
MOZ_TOOLKIT=
moz_debug=0
moz_debugger=
*** Registering -chat handler.
*** Registering x-application-irc handler.
*** Registering irc protocol handler.
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
It's NOT UTF-16LE- byte 23(17)
It's NOT UTF-16BE- byte 114(72)
Document
http://ftp.mozilla.org/pub/mozilla/nightly/2001-03-19-21-Mtrunk/linux-xpi/
loaded successfully
#> /usr/local/mozilla/run-mozilla.sh: line 72: 2405 Segmentation fault $prog
${1+"$@"}

[1]+ Done ./mozilla-installer
---

Unless you guys request something specific, I'm done with this build. It's way
too broken here.

Good Luck,

Ric

Comment 3

[Ric Johnson]

Just installed the 2001032021 Linux build.
Got the same messages as before: 'Installer module failed to install...' and
'Installation complete'.
The XPI installer is working!  I don't know which module/s was/were not
installed since the message is generic and does not specify which module or
modules failed to properly install.

This build sure is better! Thanks.

Here's the output from the console for the install and first start up(Modern
skin):

./mozilla-installer
/usr/local/mozilla/run-mozilla.sh /usr/local/mozilla/mozilla-bin -installer
MOZILLA_FIVE_HOME=/usr/local/mozilla
  LD_LIBRARY_PATH=/usr/local/mozilla:.:
     LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/components
       SHLIB_PATH=/usr/local/mozilla
          LIBPATH=/usr/local/mozilla
       ADDON_PATH=/usr/local/mozilla
      MOZ_PROGRAM=/usr/local/mozilla/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
*** Registering -chat handler.
*** Registering x-application-irc handler.
*** Registering irc protocol handler.
Registering plugin 0 for: "*","All types",".*"
It's NOT UTF-16LE- byte 23(17)
It's NOT UTF-16BE- byte 114(72)
JavaScript error: 
 line 0: uncaught exception: Scrollbars in this skin are not properly supporting
mac smart-scrolling prefs!

JavaScript error: 
 line 0: uncaught exception: Scrollbars in this skin are not properly supporting
mac smart-scrolling prefs!

Document
http://ftp.mozilla.org/pub/mozilla/nightly/2001-03-19-21-Mtrunk/linux-xpi/
loaded successfully
Runtime mismatch, so leaking context!
---

HTH
Ric
===

Comment 4

[Daniel Veditz [:dveditz]]

There should be an install log left behind -- that will tell you which modules 
had an error, and which specific error. Please let us know what you find there.

Linux installer -> sgehani

Comment 5

[Samir Gehani]

I tested the mozilla-installer: the dummy talkbac.xpi is failing.  For some
reason, bin/components/nsSample.js is not being packaged into talkback.xpi.
Yet, in a debug build from yesterday on my own machine, I used deliver.pl that
created a talkback.xpi with bin/components/nsSample.js in it.

Over to granrose to investigate why the verification build machine is apparently
behaving differently.

Pretty severe since it makes the installer look like it failed.

Comment 6

[Ric Johnson]

Mid-Air Collision Detected! Say what??? Throw away my changes or overwrite yours
- some 'choice'. grrr.

duh. sorry about the no info. Guess I was being lazy or tired again.

Talkback failed to install, as it appears you have found.

Here's the error info generated via the install.log:

-------------------------------------------------------------------------------
file:///tmp/.tmp.xi.0/bin/../talkback.xpi -- 03/21/2001 05:36:09
-------------------------------------------------------------------------------

Talkback
--------

** initInstall: 0
** communicatorFolder: /usr/local/mozilla/
** addDirectory() returned: -214

Install **FAILED** with error -214
** cancelInstall() returned: -214
Finished Installation 03/21/2001 05:36:09

-------------------------------------------------------------------------------

I have installed other *.xpi and they work.
I tried to install talkback.xpi shortly after the browser installed; it failed.
The error in the log is the same as above(time is diff, of course).

Otherwise, this is nice build. Stable - it won't crash and burn as other recent
nightlys were doing. Thanks to all.

Something else?

HTH
Ric
===

Comment 7

[Samir Gehani]

Ric,
Thanks for the input.  The problem has been identified.  

Comment 8

[Asa Dotzler [:asa]]

Setting bug status to New. 

Comment 9

[Samir Gehani]

Granrose, if you don't have time to investigate this let me know and I'll do
some quick hackery to temporarily alleviate the problem.  

Comment 10

[Jon Granrose]

samir - so this is the stub talkback.xpi file that is causing this problem, not
the full talkback.xpi that we copy out over it after the netscape build completes?

setting 0.9 to inspire me to get it fixed by then.

Comment 11

[Samir Gehani]

Jon,
Yes, somehow the stub talkback.xpi is getting shipped and this is the .xpi that
is causing the problem.  Please let me know if I can be of assistance.  

Comment 12

[Jon Granrose]

nsSample.js is no longer being built by default.  from the log file in pkgcp.pl:

bin/components/Warning: package error or possible missing file:
bin/components/nsSample.js
(/builds/client/linux22/seamonkey/mozilla/xpinstall/packager/packages-unix, 318).

so that's why it's not being packaged in the mozilla talkback.xpi.  Is there a
way to change the install.js in the stub talkback.xpi file to install nothing? 
We could package a different file in the stub talkbac.xpi file, but then we'd
run the risk of running into this same problem again in the future.

Comment 13

[Samir Gehani]

Taking  bug.

Comment 14

[Samir Gehani]

Attachment: Remove call to addDirectory().

Comment 15

[Sean Su]

r=ssu

Comment 16

[Samir Gehani]

Attachment: Same patch as above except in the mozilla tree where it really should be.

Comment 17

[Daniel (Leaf) Nunes]

sr'ing this as the nearest sr (build/config).

Comment 18

[Daniel Veditz [:dveditz]]

Why/how are people getting the stub talkback.xpi in the first place? when I 
look at the linux-xpi directory on ftp.mozilla.org it appears to be the right 
thing.

Comment 19

[Samir Gehani]

CC'ing granrose to answer dveditz's last question.  I vaguely recall being
informed that the dummy talkback.xpi is only replaced by the ns talkback.xpi for
milestone builds.  Not sure if this is the case.  I agree that we probably want
talkback.xpi to be in all builds -- milestone or not -- since users have the
choice through the cutsom dialog to deselect it.

Anyways, fix checked in.

Comment 20

[Asa Dotzler [:asa]]

If you look at most of the nightly builds for a while (with the exception of
todays) Most of the Talkback XPIs in the xpi/ directories have been broken with
a size of 1K. 

Comment 21

[Jon Granrose]

the automation copies the full talkback.xpi file from the ns tree to mozilla.org
after the ns build completes.  So there is an hour or so window after the
mozilla build completes where the stub talkback.xpi is out there (often when the
highest number of people are trying to install).  Also, the automation
occasionally fails to deliver the full talkback.xpi file to the mozilla.org
server.  Looking at this morning's 8am build (the oldest log file still handy) I
see the full talkback.xpi file was delivered this morning, and I see it on the
ftp server.

I think this bug can be safely resolved at this point.

Comment 22

[Grace Bush]

verified on build 2001041305