186088 - Mozilla crashes during installation of XPI Packages [@ nsInstallFile::CreateAllFolders]

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Greg K.]

FizzillaMach/2002121607 crashed at nsInstallFile::CreateAllFolders during
installation of the AutoScroll XPI package from
<http://dialspace.dial.pipex.com/town/pipexdsl/o/aoos87/sa/autoscroll>.

I clicked the install link, and approved the installation. The installation
progress dialog appeared, showing a progress meter which filled, then turned
indeterminate (barber-pole pattern). Mozilla crashed at that point.

The crash was, and is, reproducible.

Comment 1

[Greg K.]

Attachment: Crash report generated by FizzillaMach/2002121607 showing crash at nsInstallFile::CreateAllFolders on thread 23

Comment 2

[Jimmy Lee]

Build: 2002-12-20-08-trunk (MAC OS X)

I cannot reproduce the crash with this build.  Greg, can you try a more current
build?  I'm not sure what changes between builds could have affect this.

Comment 3

[Greg K.]

Still crashes FizzillaMach/2002122307. Jimmy, are you testing a CFM or Mach build?

Comment 4

[Jimmy Lee]

CFM for me.

Comment 5

[Greg K.]

Again crashed installing CaScadeS into FizzillaMach/2002122307. Generalizing
summary.

Comment 6

[Paul Everitt]

Crashes for me when installing Googlebar, and also when installing 
my own XPI.  For mine, I put alert boxes before/after every line 
in the XPI (logComment didn't help), to narrow down the problem.

In mine, addFile was the offender.

Comment 7

[Greg K.]

Still crashes using FizzillaMach/2003021017, generating TB160571W.

Comment 8

[[e-mail]]

I've noticed this with our spell checker XPI, it seems to crash when creating
new directories...

Comment 9

[Matthias Versen [:Matti]]

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

Comment 10

[[e-mail]]

I haven't looked at his crasher yet, we've been seeing crashers on OS X. There 
is a workaround - every directory has to be created explicitly before 
attempting to write to it. We used this successfully:

f = getFolder("parentDirectory", "myNewDirectory");
err = File.dirCreate(f);

There seems to be an issue with file permission, when directories are not 
created explicitly (http://mozdev.org/bugs/show_bug.cgi?id=3192). 

I'm not sure if and how all if this relates to the issue at hand, but I'll look 
into it later today.

Comment 11

[Christopher Mason]

Occurs in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b)
Gecko/20030210 with http://downloads.mozdev.org/optimoz/mozgest_0_3_5.xpi on OS
X 10.2.4 (6I32).

-c

Comment 12

[Sean Su]

Might be a dupe of bug 178546 given comment #6

Comment 13

[Greg K.]

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

Comment 14

[Michael Eibl]

1.3 does not crash, it just stops loading the xpi file. Tested with
"mozilla-1.3-lang-de-AT.xpi".

Regards,
Michael

Comment 15

[Daniel Veditz [:dveditz]]

Yes, XPInstall was disabled on OSX for the 1.3 release -- see the release notes.

Comment 16

[Samir Gehani]

Installer triage team: nsbeta1+/adt1

Comment 17

[Sean Su]

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

Comment 18

[Sean Su]

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

Comment 19

[Sean Su]

Here are a couple of other urls that can reproduce the crash:
 (external) http://leech.mozdev.org/installation.html (install leech)
 (internal)
http://blues/users/gbush/publish/buffy/install/xpinstall-tests-buffy.html

I was able to track down to where I believe is causing this bug:
  http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileOSX.cpp#1158

Here is the basic idea of how the crash is happening.  In an install.js script,
the following function calls are done explicitly and implicitly (this is not a
stack trace, but function calls that are called in this order for the crash to
happen):
 -> nsInstall::addSubComponent() or nsInstall::addDirectory()
 -> nsInstallFile::Prepare()
 -> nsLocalFileOSX.cpp's nsLocalFile::GetParent() (return from this function
    and immediately crash on the next function call)
 -> nsInstallFile::CreateAllFolders(): 
http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsInstallFile.cpp#266

The reason is because nsLocalFileOSX::GetParent() is returning null for
'parent'.  Granted, we should be checking for null pointers and the error code
from GetParent() here in addition to fixing GetParent().

Conrad, do you know if your new nsLocalFileOSX code has this fixed?  Can you try
the URL test cases, or if you have a patch, I can help verify this fix too.

Comment 20

[Bjarne D Mathiesen]

As to xpi-projects, that crash Mozilla on Mac OS X I can add a juicy one:
I compiled Mozilla 1.3final under Mac OS X 10.2.4 following all of the
instructions on the relevant pages. Now, Mozilla + Calendar were running
beautifully together when Calendar was compiled into the package, but when I
then made an *.xpi to enable install on a distribution binary, I got the
infamous crash when using Mozilla 1.3rc2

Do you want the calendar_mac.xpi for testing ???

Comment 21

[Conrad Carlen (not reading bugmail)]

Sean, the new code had this fixed, but... See
http://bugzilla.mozilla.org/show_bug.cgi?id=164396#c14 :-(

What you pointed out:
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileOSX.cpp#1158
is a problem. I'm not sure why that return statement is there - it should be
removed. 

Comment 22

[Sean Su]

yeah, I forgot to mention that line is causing a premature return.  I just
commented that return out and everything works.

patch coming up.

Comment 23

[Sean Su]

Attachment: patch v1.0

Comment 24

[Sean Su]

Comment on attachment 118054 [details] [diff] [review]
patch v1.0

removing this return fixes the premature return.

Comment 25

[Conrad Carlen (not reading bugmail)]

Comment on attachment 118054 [details] [diff] [review]
patch v1.0

r=ccarlen

Comment 26

[Daniel Veditz [:dveditz]]

Comment on attachment 118054 [details] [diff] [review]
patch v1.0

sr=dveditz

Comment 27

[Sean Su]

patch checked in.  closing bug as fixed.
on to other osx bugs now...

Comment 28

[Bjarne D Mathiesen]

have just tested 2003-03-24-16:

the following xpi's that previously crashed on install now install properly:
calendar-mac , leech 1.1.0 , cascades 0.3

Comment 29

[Grace Bush]

verified installing enigmail and cascades
2003032503

Comment 30

[Sean Su]

patch merged to 1.3 branch