94568 - crash when attempting xpinstall after modifying prefs

Status: VERIFIED FIXED

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

Description

[Dave]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010808
BuildID:    2001080821

If I modify my prefs (Edit->Preferences...) and then attempt to install an xpi
package off ftp.mozilla.org (talkback, in my case), the browser crashes.
This doesn't happen if I haven't changed any of my prefs since starting the browser.
This may be a dupe since there're already a few bugs about xpinstall crashing
the browser but I can't be sure about any of them...

Reproducible: Always
Steps to Reproduce:
1. Start browser
2. Open Edit->Preferences...
3. Make a change (removing a toolbar button, for e.g.) and hit enter
4. Go to the above URL and left click on one of the xpi files
5. Browser crashes

Actual Results:  Browser crashes before xpinstall has a chance to run

Expected Results:  xpi package should be installed.

Comment 1

[Dave]

Submitted talkback TB33880653H

Comment 2

[Daniel Veditz [:dveditz]]

The stack trace for that talkback incident is complete mush. Here's a bit from
the middle:

GlobalWindowImpl::GetRootFocusController()
nsInstallFileOpItem::Prepare()
nsInstallFileOpItem::toString()
nsInstallVersion::CompareTo()
nsInstallVersion::QueryInterface()
nsDocLoaderImpl::QueryInterface() 

QueryInterface() shouldn't be calling other functions, certainly not
nsInstallVersion::CompareTo(); an nsInstallVersion method isn't going to know
anything about a nsInstallFileOpItem object, and in any case CompareTo operates
on the internal data of two nsInstallVersions; CompareTo is called in a user
script, but install queue objects Prepare() methods are called from the related
nsInstall method, and needless to say a nsInstallFileOpItem doesn't know
anything about the GlobalWindowImpl.
What's going on, memory corruption?

When does the crash occur? Before the install confirmation dialog has appeared?
DUring the download?

Comment 3

[Dave]

The crash occurs a second or so after clicking the link (the xpinstall confirm
dialog isn't visible yet).
It also appears that it's not necessary to change anything in prefs in order to
cause the crash. It's sufficient to open prefs and immediately hit cancel.

Here're a couple talkbacks I submitted on trunk build 2001080509/Linux here at
home (both machines are running Debian woody):

TB33812647X
TB33893364G

Comment 4

[Dave]

Just ran mozilla through strace in case that's of any use. The file I'm about to
attach contains the output from running

strace ./mozilla > strace.out 2>&1

with the browser doing the following:

- start and load homepage
- pull up prefs window and hit cancel
- start typing in location bar until desired url from ftp.mozilla.org appears
- go to url and click on talkback.xpi
- browser crashes and talkback starts up

Comment 5

[Dave]

Attachment: output of running mozilla through strace

Comment 6

[Dave]

Oh... sorry about the spam but both machines are running precompiled debian 2.4
kernels (2.4.5-686 and 2.4.7-686).

Comment 7

[Syd Logan]

Jimmy, have you been able to duplicate this? if not, I am thinking we should
take off nsbranch because this bug is not being seen on a tier 1 platform (we
only support RedHat Linux, not Debian). Please advise.

Comment 8

[Dave]

I'm not seeing it anymore with 2001090409/Linux... I guess it's a WFM now.

Comment 9

[Syd Logan]

Reporter claims this is worksforme.

Comment 10

[Jimmy Lee]

Build: 2001-09-05-08-trunk(LINUX)

I cannot reproduce the crash.  Marking Verified.