144331 - Previous setting of MOZILLA_FIVE_HOME blocks Installer

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Marcelo de G. Malheiros]

I've used Mozilla 1.0 RC1 since its release, and for acessing it everywhere I
copied the "mozilla" script to my path and set MOZILLA_FIVE_HOME in my .profile
to the location where I've installed the other Mozilla files.

Everything was fine until today, when I tried to install the new RC2. The
installation went fine till the part where the modules were extracted, then it
simpled stopped with the error 620 and froze. It took me some time to find that
unsetting the MOZILLA_FIVE_HOME before made the installation finish normally.
After that it's fully functional again.

Comment 1

[Marcelo de G. Malheiros]

I've just installed RC3 and the bug still exists. This time the installer simply
dumped core in the middle of the installation (during the unpacking step).

After unsetting the variable everything worked fine.

Comment 2

[Kai Lahmann (is there, where MNG is)]

reporter (Marcelo Malheiros): can you reproduce this bug with a recent build of
mozilla (for example, 1.1beta)? if so, please comment again with details. if
not, please resolve this bug as WORKSFORME. thanks.

Comment 3

[Andrew Schultz]

I'm seeing this too.  I think most people don't see this because they don't set
the variable.  To get the crash, you need to point it to a mozilla directory
that is sufficiently out of date (1.0).  Pointing it at a recent nightly build
gives errors, but does not crash.

stracing the installer showed it reading a lot of the shared libs and .xpt files
in the MOZILLA_FIVE_HOME directory and even trying to write to some of them.

The reasonable solution here is to simply have the mozilla-installer script
unset the MOZILLA_FIVE_HOME variable.  That fixes the crash.

Comment 4

[Andrew Schultz]

Attachment: patch

unset MOZILLA_FIVE_HOME

Comment 5

[Tom]

I've been seeing this as well, and I have MOZILLA_FIVE_HOME=/usr/local/mozilla
where /usr/local/mozilla->/usr/local/mozilla-nightly which was always empty
prior to installation. Unsetting MOZILLA_FIVE_HOME fixed it for me.

Comment 6

[Andrew Schultz]

*** Bug 164826 has been marked as a duplicate of this bug. ***

Comment 7

[Andrew Schultz]

*** Bug 165210 has been marked as a duplicate of this bug. ***

Comment 8

[Andrew Schultz]

dveditz, could you review the patch here?

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 93910 [details] [diff] [review]
patch

r=dveditz

Thanks for tracking this down!

Comment 10

[Andrew Schultz]

*** Bug 173342 has been marked as a duplicate of this bug. ***

Comment 11

[Andrew Schultz]

*** Bug 184844 has been marked as a duplicate of this bug. ***

Comment 12

[K'Trina Medina]

*** Bug 182568 has been marked as a duplicate of this bug. ***

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 93910 [details] [diff] [review]
patch

r+sr=dveditz for this trivial install patch.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 93910 [details] [diff] [review]
patch

r+sr=dveditz for this trivial install patch. Requesting 1.3 approval as this
issue causes us a bunch of grief each milestone.

Comment 15

[Daniel Veditz [:dveditz]]

Fix checked in

Comment 16

[Andrew Schultz]

fixed

Comment 17

[Grace Bush]

verified

Comment 18

[Philip K. Warren]

I have a general question about this patch. Is there a reason why "export -n" is
used instead of "unset"? GNU bash is the only shell I'm aware of that supports
"export -n", and this change has made it where the mozilla-installer script now
fails on other UNIX platforms (tested on Solaris and AIX).

Solaris gives the following error message:
./mozilla-installer: -n: is not an identifier

AIX gives the followng error message:
./mozilla-installer[41]: export: bad option(s)