120446 - dummy mozilla talkback.xpi crashes xpinstall

Status: RESOLVED DUPLICATE of bug 124525

Description

[Sean Su]

The place holder talkback.xpi created by mozilla builds crashes xpinstall.  It
looks like for every initInstall(), there needs to be a corresponding
performInstall().

It currently only calls cancelInstall().  Removing this call altogether still
causes the crash.  However replacing it with a call to performInstall() fixes it.

I'm not sure exactly what's causing this new crash, but since the place holcer
talkback.xpi is only a place holder, and there are more urgent fixes out there
than this one, I'm going to propose this fix.  Patch coming up.

Comment 1

[Sean Su]

Created attachment 65355 [details]
bad xpi file.

This is the place holder talkback.xpi file that causes the crash.  I'm
attaching it here because release eng. replaces this file with the correct copy
before uploading it to mozilla.org (meaning there is no way to test this
without this attachment).

To verify that the crash happens:
  1) download a mozilla blob build from mozilla.org
  2) run 'mozilla-win32-sea-installer.exe -u'
  3) replace the talkback.xpi with the one attached in this bug.
  4) run 'setup.exe' and install the default setup type.

The crash will happen at the end of the file copying process.  Talkback is the
last component to be installed.

ps. I need this crash problem fixed because it's causing me lots of grief when
I try to help debug/verify xpinstall fixes.

Comment 2

[Sean Su]

Created attachment 65357 [details] [diff] [review]
patch

Comment 3

[Daniel Veditz [:dveditz]]

InitInstall/cancel is allowed, and certainly shouldn't crash. initInstall()
alone should even "work", returning an MALFORMED_INSTALL (-240) error.

Is there a bug filed on the crash itself? a workaround is fine for now, but the
crash could easily signal a worse problem and shouldn't be swept under the rug.

Once the crash is fixed should we undo this workaround? cancelInstall() returns
an error code, so if anyone gets this file by mistake they'll know it, with
performInstall() people might think the install went fine. On the other hand an
error will make the native installer stubs unhappy when mozilla itself installed
fine. Periodically we do ship nightly linux builds in this state and get complaints.

Maybe the answer is to go ahead and performInstall() so there's a SUCCESS
result, but to logComment("****Warning: placeholder talkback.xpi, talkback not
installed") and maybe even put up an alert(). 

TRying an alert may hang or crash, I think I'll have to make xpistub supply an
nsIPromptService for that to work. That's platform-specific code, may have to
get the native installers to provide it, but they don't know squat about xpcom. bah!

Comment 4

[Sean Su]

Created attachment 67319 [details]
starck trace of the crash

Comment 5

[Stephan Grossklass]

Can't reproduce with 1.7b and the given bad XPI, probably long fixed.

Comment 6

[Asa Dotzler [:asa]]

worksforme with windows 1.7 beta. did this workaround get landed? is this still
a problem for anyone?

Comment 7

[John Carter]

(In reply to comment #6)
> worksforme with windows 1.7 beta. did this workaround get landed? is this still
> a problem for anyone?

Downloaded latest-trunk full installer yesterday 13 April 2004, got the
following message during the "Installing Quality feedback Agent" phase...

Error[621]: An Installer module talkback.xpi (.xpi) failed to install.

Comment 8

[John Carter]

(In reply to comment #7)
> Downloaded latest-trunk full installer yesterday 13 April 2004, got the
> following message during the "Installing Quality feedback Agent" phase...
> 
> Error[621]: An Installer module talkback.xpi (.xpi) failed to install.

just noted this bug is against Win2k OS, the I'm working on Linux Debian

Comment 9

[timeless]

*** This bug has been marked as a duplicate of 124525 ***