Closed Bug 259688 Opened 20 years ago Closed 17 years ago

Crash [@nsCOMPtr_base::~nsCOMPtr_base] [@ 0x003a0043] installing themes and extensions (clicking twice on the same install)

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9beta1

People

(Reporter: jay, Assigned: mossop)

References

Details

(4 keywords)

Crash Data

Attachments

(2 files, 1 obsolete file)

Early Talkback data is showing A LOT of users crashing installing various
themes.  It is across all 3 platforms and although the stacks don't seem to be
very helpful, we need to look into this crash asap.  Here are 3 sets of crashes,
one for each platform:

Rank    StackSignature    Count  

2   nsCOMPtr_base::~nsCOMPtr_base   243 

 
 	Source File :
/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp
line : 81
 
====================================================================================================
     Count   Offset    Real Signature
[ 71   nsCOMPtr_base::~nsCOMPtr_base beb036a1 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 65   nsCOMPtr_base::~nsCOMPtr_base d45f84c2 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 31   nsCOMPtr_base::~nsCOMPtr_base c7bb9732 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 19   nsCOMPtr_base::~nsCOMPtr_base e20f9e32 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 7   nsCOMPtr_base::~nsCOMPtr_base e9667ab7 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 5   nsCOMPtr_base::~nsCOMPtr_base f0faedf1 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 3   nsCOMPtr_base::~nsCOMPtr_base cc3ff401 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 2   nsCOMPtr_base::~nsCOMPtr_base fa6feef1 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 2   nsCOMPtr_base::~nsCOMPtr_base ce4b82f0 - nsCOMPtr_base::~nsCOMPtr_base ]
 
     Crash date range: 14-SEP-04 to 15-SEP-04
     Min/Max Seconds since last crash: 82 - 50206
     Min/Max Runtime: 82 - 50206
 
     Count   Platform List 
     166   Windows XP [Windows NT 5.1 build 2600] 
     39   Windows 2K [Windows NT 5.0 build 2195] 
 
     Count   Build Id List 
     205   2004091322
 
     No of Unique Users       201
 
 Stack trace(Frame) 

	 nsCOMPtr_base::~nsCOMPtr_base
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 81] 
	 _PR_NativeRunThread
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/nsprpub/pr/src/threads/combined/pruthr.c
 line 455] 
	 kernel32.dll + 0xb50b (0x7c80b50b)   
 
     (819197)	Comments: Downloaded Noia Theme
     (819134)	Comments: downloading/installing Download Manager Tweak 0.5.2
     (819119)	Comments: Multiple downloads of the same theme
     (819094)	URL: www.mozilla.org
     (819094)	Comments: Installing themes. Crash when "Lure" theme completed
download.
     (819055)	Comments: Installing a theme
     (818994)	Comments: installing extensions
     (818901)	Comments: Installing Noia Extreme Theme
     (818817)	Comments: Firefox failed while downloading a new theme. 
     (818541)	Comments: I switch to Internet Explorer. For some reason  Firefox
doesn't allow me to play flash.
     (818030)	Comments: Instaling new themes Naio  
     (817863)	Comments: Installing themes
     (817814)	Comments: Theme download - notification of incompatibility
     (817187)	URL: mozilla.org/themes
     (817187)	Comments: I was browsing for available themes in PR1.0 while
installing the few that were readily accessible from the main theme page.
     (816927)	Comments: I was installing the new Noia 2.0 theme release
September 9th at the same time that I was deleting the old Noia 2.0 theme (v2.75).
     (816892)	URL: texturizer.net
     (816892)	Comments: browsing for new themes for the browser  one was
downloading in the background and it crashed
     (816200)	Comments: I was picking theme.  
     (815668)	Comments: Downloading a new theme (it was stuck at "waiting..."
when FireFox crashed).
     (815631)	Comments: Tried to install a new theme.
     (815042)	Comments: Installing themes
     (814046)	Comments: I was installing a new theme  Noria 2.0
     (813964)	Comments: getting themes
     (813333)	Comments: trying to add a theme noia 2.0 which was advertised as
being compliant with pr1.0  but a dialog popped up saying it wasn't shortly
after which the browser politely exited.
     (812745)	URL:
https://update.mozilla.org/themes/?application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
     (812745)	Comments: I was installing newer themes for it  I then got a
message that the theme I choose wasn't compatible with the latest version of
Firebox & then it crashed on me.
     (812737)	Comments: Adding Qute theme (it gave an error saying it would only
work with Firefox 0.8 or 0.9).  I am running 0.10
     (812442)	Comments: trying to install a theme from firefox website
     (812274)	Comments: I was installing the Qoia (sp?) Extreme theme when
Firefox failed.
     (812201)	URL: www.mozilla.org/theme_firefox
     (812201)	Comments: I was installing a theme (modern skin v.0.7)
     (812191)	URL: www.mozilla.org/theme_firefox
     (812191)	Comments: I was installing a theme (modern skin v.0.7)
     (811791)	Comments: downloading themes
     (811310)	Comments: Using the Themes manager caused the app to fail.
     (811145)	URL: It was the theme page on update.mozilla.org
     (811145)	Comments: I was browsing themes.
     (811129)	Comments: downloading themes
     (810734)	URL: On the themes site on mozilla.org
     (810734)	Comments: Downloading Theme
     (810545)	URL: https://update.mozilla.org/themes/moreinfo.php?id=76&vid=687
     (810545)	Comments: Tried to install the Doodle (Classic) 1.5.8.1 theme
     (810532)	Comments: installing themes from the mozilla site
     (810523)	Comments: Installing theme noia extreme
     (810519)	Comments: Installing theme
     (810491)	URL: update.mozilla.org
     (810491)	Comments: trying to install the Nutopolis theme which is not
compatible with FF 1.0PR
     (810373)	Comments: downloading a theme.
     (810297)	Comments: downloading noia extreme theme
     (810116)	Comments: Installing Firefox extensions
     (810059)	Comments: I was downloading new themes.
     (810019)	URL: update.mozilla.org
     (809995)	Comments: Tried to install a theme but nothing happend  so when I
was reading the comments it suddenly came up with the install dialog 4-5 times
and then crashed
     (809805)	Comments: on a web page  Click on install Noia theme: 2 times
     (809674)	Comments: had click on install mouse gestures several times  so
there were lots of boxes coming up asking if I wanted to install a new plugin
     (809590)	Comments: Installing a new theme
     (809456)	Comments: browser crashed when installing theme which apparently
doesn't work with 1.0PR
     (809437)	URL: https://update.mozilla.org/themes/
     (809437)	Comments: Downloading a theme
     (809384)	Comments: installing theme noia lite
     (809300)	Comments: installing Pinball theme
     (809108)	Comments: Installing new theme
     (808963)	Comments: Installing theme
     (808945)	Comments: Trying to read slashdot.org while updating the
Noia2extreme theme.  Clicked the download button thrice because nothing seemed
to be happening  then a few minutes later accepted the first "do you want to
install this" window  and cancelled out of the
     (808945)	Comments:  others that popped up minutes later.
     (808927)	Comments: i was getting a theme when the browser just died
     (808835)	Comments: Installing a theme
     (808751)	Comments: trying to install the SphereGnome 0.9.7 theme from
update.mozilla.org
     (808721)	URL: http://www.deviantart.com/download/5706856/
     (808491)	Comments: installing themes
     (808390)	Comments: Tools->Themes->Select Noia 2 - (pre PR 1
verison)->Update   asks if you want to update  yes.  asks if you want to
install  yes.  clicked on another theme  clicked on update... said was
downloading noia...closed progress box  boom - crash.
     (808030)	Comments: playing pool online and getting new themes for mozilla
firefox 1.0
     (807964)	Comments: Clicked on multiple theme install links in several
different tabs
     (807900)	Comments: Trying to install the Pinball theme from the Mozilla
Firefox themes website.
     (807824)	Comments: Was trying to install the Phoenity theme. Got a box
saying  it didn't support the new 1.0PR version. Then got the fault  screen.
Also  had trouble getting Phoenity plug-in to install.  Clicked the install
button from the firefox extensions website  and
     (807824)	Comments:  nothing happened. Clicked several more times and
checked  javascript console--nothing-no feedback that something was happening.
After a long time  a java script popup appeared asking if I wanted to install
the theme. I clicked yes..and it appeared in the
     (807824)	Comments:  theme download box as installing...then after a couple
more minutes pop-ups from the other clicks I'd done started showing up.  I
dismissed them all and the download finally started moving in the theme manager
window. 
     (807729)	Comments: I tried to install "phoentry" (or something like it) theme
     (807630)	Comments: installing themes
     (807615)	Comments: Installing the easyGestures plugin from the Mozilla site
     (807604)	Comments: nothing
     (806829)	URL: www.mozilla.org
     (806704)	Comments: installing a theme (Noia eXtreme)
 
====================================================================================================
     Count   Offset    Real Signature
[ 2   nsCOMPtr_base::~nsCOMPtr_base() ce68d97b - nsCOMPtr_base::~nsCOMPtr_base() ]
 
     Crash date range: 14-SEP-04 to 14-SEP-04
     Min/Max Seconds since last crash: 0 - 0
     Min/Max Runtime: 0 - 0
 
     Count   Platform List 
     1   [Linux 2.6.8.1-ck7]      
     1   [Linux 2.6.3-16mdk-i686-up-4GB]      
 
     Count   Build Id List 
     2   2004091400
 
     No of Unique Users         2
 
 Stack trace(Frame) 

	 nsCOMPtr_base::~nsCOMPtr_base()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 80]  
 
     (807841)	Comments: pressed ctrl-T to bring up new window
 
====================================================================================================
     Count   Offset    Real Signature
[ 2   nsCOMPtr_base::~nsCOMPtr_base() 47b23aaa - nsCOMPtr_base::~nsCOMPtr_base() ]
 
     Crash date range: 14-SEP-04 to 14-SEP-04
     Min/Max Seconds since last crash: 471 - 1315
     Min/Max Runtime: 471 - 1315
 
     Count   Platform List 
     2   [Darwin 7.5.0]      
 
     Count   Build Id List 
     2   2004091322
 
     No of Unique Users         2
 
 Stack trace(Frame) 

	 nsCOMPtr_base::~nsCOMPtr_base()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 81] 
	 nsXPITriggerInfo::~nsXPITriggerInfo()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsXPITriggerInfo.cpp
 line 123] 
	 nsXPInstallManager::Release()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsXPInstallManager.cpp
 line 120] 
	 nsInstallInfo::~nsInstallInfo()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsInstall.cpp
 line 115] 
	 RunChromeInstallOnThread()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp
 line 763] 
	 _pt_root()
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/nsprpub/pr/src/pthreads/ptthread.c
 line 217] 
	 libSystem.B.dylib.71.1.1 + 0x246e8 (0x900246e8)   
 
     (810618)	URL: index.hu
     (810618)	Comments: installing a theme
     (810081)	Comments: I had just installed 1.0 PR. I was trying to find some
themes that would work in it. I had installed 70809 lite and when I clicked on
it in the theme selector  Firefox crashed.  Also of note  themes that work on
the Windows version (Orbit grey) get an
     (810081)	Comments:  uncompatible error on MacOS X. Yes  they are both new
installs 1.0 PR  and I never had problems in either environment in the previous
release.
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
I spent some time testing themes today with a recent build (Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041004
Firefox/0.10.1), including ones that are not compatible with OSX. Despite the
fact that I switched back and forth between a dozen themes, I did not experience
any crashes on my system. I will try this on the nightly and see if I get
similiar results.
Whiteboard: can't reproduce yet
Using today's Windows build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20041007 Firefox/0.10.1 I installed the following themes:
Lure, Qute, Firefox Modern, Firecat AutumnRedCB, Noia Lite and Extreme, Curacao,
and Plastikfox Crystal SVG. I switched back and forth between the themes and
experienced no crashes.
- until there's a reproducible test case. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
I don't know if this is the same behaviour, but some of the comments also
mention problems with the extensions and the TB data seems to fit.

I tried to installed the extension weaterfox extension 0.5.1 from
http://weatherfox.mozdev.org/installation.html
I clicked in a short time (approx. 2 sec.) several (approx. 4) times on the
installation link. I confirmed the first and canceled all other extension
installer dialog boxes. Firefox crashes after I cancelled the last dialog.

TB1673528M
TB1673577G
Talkback data is still showing this as a topcrash for FF10RC1 and FF10RC2:

RC1:
 Count   Offset    Real Signature
[ 30   nsCOMPtr_base::~nsCOMPtr_base beb036a1 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 7   nsCOMPtr_base::~nsCOMPtr_base 017953d6 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 5   nsCOMPtr_base::~nsCOMPtr_base c7bb9732 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 3   nsCOMPtr_base::~nsCOMPtr_base d45f84c2 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 2   nsCOMPtr_base::~nsCOMPtr_base e20f9e32 - nsCOMPtr_base::~nsCOMPtr_base ]
[ 2   nsCOMPtr_base::~nsCOMPtr_base 68985987 - nsCOMPtr_base::~nsCOMPtr_base ]
 
     Crash date range: 01-NOV-04 to 31-OCT-04
     Min/Max Seconds since last crash: 55 - 347732
     Min/Max Runtime: 55 - 347732
 
     Count   Platform List 
     37   Windows XP [Windows NT 5.1 build 2600] 
     12   Windows 2K [Windows NT 5.0 build 2195] 
 
     Count   Build Id List 
     49   2004102622
 
     No of Unique Users        49
 
 Stack trace(Frame) 

	 nsCOMPtr_base::~nsCOMPtr_base
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 81] 
	 _PR_NativeRunThread
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/nsprpub/pr/src/threads/combined/pruthr.c
 line 455] 
	 kernel32.dll + 0xb50b (0x7c80b50b)   
 
     (1668281)	URL: http://football.guardian.co.uk/livescores
     (1658678)	Comments: Crashed after downloading a theme(Curracao) while
loading a bightml file(a large table)
     (1637080)	Comments: Downloading new skins to FireFox 1.0 RC
     (1604385)	Comments: tring to load the Noka theme..might add to NOTHING
works with this version.... themes...extensions...nothing..very weak
     (1600953)	Comments: installing an extension.  accidentally clicked install
link twice  hit INSTALL once  hit CANCEL for second install dialog.
     (1581584)	Comments: installing themes for 1.0PR
     (1580340)	Comments: Tried to install the Qute theme (apparently for 0.10)
from the author's homepage.   After it notified me it was incompatible  it went
*BOOM* !!!
     (1578319)	Comments: installing web developer tools 0.8 
     (1576128)	Comments: Downloading themes for Firefox rc1.
     (1575595)	Comments: installing the user agent switcher extension
     (1574578)	Comments: Installing themes
     (1569642)	Comments: Downloading extention 
     (1569128)	Comments: error while installing SphereGnome theme
     (1566386)	Comments: tried to installed the Theme called NOIA extreme to the
FF 1.0 CR    ps.: for god's sake make the text size of  the toolbar address at
least twice bigger. Or even better: make this customizable form the 
tool-option-font . This is vital for those using a
     (1566386)	Comments:  laptop with high resolution display     Also replace
the Bookmark menu by a big letter "B"  the Tool menu by  big letter "T" and the
Help menu by a question mark "?". those letters and question mark will be
respectively inside a squares (for the two big
     (1566386)	Comments:  letters) and a circle ( for the ?). and for god;s sake
use the noia extrem for your default theme  making the squared-background of e
those letter B and T behaving like a liquide when the cursor is on them. But
instead of using the color blue liquified 
     (1566386)	Comments:  use instead green liquified for the letter B while a
red-crimson liquifide color for the letter T. this will also give more space for
the tool bar address. very useful when one is using a laptop.
 
Not enough data for RC2 yet, but I do see a few crashes that mention installing
various themes and extensions in the user comments.
Summary: FF10PR1 Crash installing themes [@ nsCOMPtr_base::~nsCOMPtr_base] → FF10RC2 Crash installing themes [@ nsCOMPtr_base::~nsCOMPtr_base]
This is clearly the #1 topcrash with Firefox 1.0.  User comments still include
installing various themes and extensions as the reason for the crash.
Summary: FF10RC2 Crash installing themes [@ nsCOMPtr_base::~nsCOMPtr_base] → FF10 Crash installing themes and extensions [@ nsCOMPtr_base::~nsCOMPtr_base]
It just happened to me (TB1902856H) when I was NOT installing anything. I just
closed a tab.
Perhaps it will help pinpointing it...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
(In reply to comment #7)
> I just closed a tab.

Tht could be also bug 265790. See the comments 32 and 33 in that bug.
Looking at crashes in nsCOMPtr_base::~nsCOMPtr_base where the user comments
mention installing themes or extensions:

The stack traces on Windows tend to look like this (clearly corrupt):


    	nsCOMPtr_base::~nsCOMPtr_base 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 81]
    	_PR_NativeRunThread 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/nsprpub/pr/src/threads/combined/pruthr.c,
line 455]
    	KERNEL32.DLL + 0xb388 (0x7c57b388) 

The stack traces on Linux tend to look like this:


    	nsCOMPtr_base::~nsCOMPtr_base() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 81]
    	nsInstallInfo::~nsInstallInfo() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpinstall/src/nsInstall.cpp,
line 115]
    	nsSoftwareUpdate::InstallJarCallBack() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpinstall/src/nsSoftwareUpdate.cpp,
line 394]
    	RunInstallOnThread() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp,
line 710]
    	_pt_root() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/nsprpub/pr/src/pthreads/ptthread.c,
line 217]
    	libpthread.so.0 + 0x6201 (0x40168201) 	 


The stack traces on Mac tend to look like this:


    	nsCOMPtr_base::~nsCOMPtr_base() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 81]
    	nsXPITriggerInfo::~nsXPITriggerInfo() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsXPITriggerInfo.cpp,
line 123]
    	nsXPInstallManager::Release() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsXPInstallManager.cpp,
line 120]
    	nsInstallInfo::~nsInstallInfo() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsInstall.cpp,
line 115]
    	nsSoftwareUpdate::InstallJarCallBack() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsSoftwareUpdate.cpp,
line 115]
    	RunInstallOnThread() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp,
line 508]
    	_pt_root() 
[/builds/tinderbox/firefox-1.0/Darwin_7.4.0_Clobber/mozilla/nsprpub/pr/src/pthreads/ptthread.c,
line 217]
    	libSystem.B.dylib.71.1.1 + 0x246e8 (0x900246e8) 	 


I do wonder whether there are any threadsafety assertions of interest when doing
installs.  I've certainly noticed them in the past.
It's worth noting that a common thread among the user comments (more so among
the ones in a current query than the ones above) seems to be attempting the
install multiple times, for example:

Trying to add an extension. Clicked "Install" 3 times, but popup wasn't
happening. Eventually started the install, then again, then again.

downloading an extension, opine-it! Download was stuck on witing, closed
extensions and extensions window poped up again, clicked on install again,
firefox downloaded it. Then it crashed.

installing drag to extention - more than once cause when i click to install it
there was no positive response that it was in progress so i clicked it a few
times and then did a cancel and thats when it crashed.

 I downloaded a theme and surfed to another one i wanted to install next.
Suddenly the browser shut down,

I was adding extensions - two windows loading the same extension popped up. I
killed the second one. This happened twice and then crash...

Trying to install the Saferfox Xpanded theme. Clicked twice on the jar-link,
cancelled the second when it started, installation seemed to go ahead, crach
when installation bar completed

Installing extentions and clicked more than once to install. I canceled 2 other
instances of the same extention install at which point I recieved th error

 trying to install adblock extension. clicked on it twice and closed one while
the other was loading.
One thing that bugs me just looking at the code is the use of the software
update service in RunInstallOnThread.  The SetActiveListener calls are
essentially the setting and nulling out of a global variable, with no lock
protection -- and there seems to be an assumption that it will remain the active
listener for the duration of the function, until it is cleared.

Also, it seems like the mJarInstallQueue in nsSoftwareUpdate is not adequately
protected.  The worst problem seems to me that if nsSoftwareUpdate::InstallJar
is called twice in rapid succession, causing two new threads to be created, and
the second thread finishes first, the wrong nsInstallInfo objects will be
deleted when the threads RunInstallOnThread methods call
softwareUpdate->InstallJarCallBack().
> Also, it seems like the mJarInstallQueue in nsSoftwareUpdate is not adequately
> protected.

"not adequately protected" isn't really what I mean.  It seems like
inappropriate use of a global variable in multithreaded code, and I don't think
there's a way to make it "adequately protected".
Whose baby is this?

/be
This ought to be mine.
Assignee: bugs → dveditz
I got an assertion when performing the steps of comment 4:
> ###!!! ASSERTION: nsGlobalWindow not thread-safe: 
> '_mOwningThread.GetThread() == PR_GetCurrentThread()', 
> file w:/mozilla/dom/src/base/nsGlobalWindow.cpp, line 338

After the crash WinDbg gives the following stack output:
(I selected hopefully the correct thread)
> WARNING: Stack unwind information not available. Following frames may be wrong.
> ntdll!KiFastSystemCallRet
> MSVCR71D!_XcptFilter+0x3d
> MSVCR71D!_threadstartex+0xdf
> MSVCR71D!_except_handler3+0x61
> ntdll!RtlConvertUlongToLargeInteger+0x7a
> ntdll!RtlConvertUlongToLargeInteger+0x46^
> ntdll!KiUserExceptionDispatcher+0xe
> xpinstal!nsInstallInfo::~nsInstallInfo+0x49
> xpinstal!nsInstallInfo::`scalar deleting destructor'+0xf
> xpinstal!nsSoftwareUpdate::InstallJarCallBack+0x5b
> xpinstal!RunInstallOnThread+0x59c
> nspr4!_PR_NativeRunThread+0xd9
> nspr4!pr_root+0x17
> MSVCR71D!_threadstartex+0xb6
> kernel32!GetModuleFileNameA+0x1b4
Whiteboard: can't reproduce yet → DUPEME can't reproduce yet
I don't know if it's the same problem. On Windows 2000 sp4.
Using Firefox 1.0.1
Amytime I try to install an extention, I can't start firefox after the install.
I get a temp folder under the extention folder. I need to delete this folder and
restore the files from the extention folder to their previous state to be able
to start Firefox.
My problem started just after the update to 1.0.1. All was fine with version 1.0.0
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.1

Similar to comment #4, I visited chromedit (http://cdn.mozdev.org/chromedit/)
and accidentally clicked the XPI link
(http://downloads.mozdev.org/cdn/chromedit/chromedit.xpi) twice. I clicked
install on the 1st install dialog box that popped up, canceled the 2nd one that
popped up. Then, I Alt+Tabbed to the extensions window, scrolled down to make
sure it said that chromedit would install on restart, close the extensions
window and then closed firefox (I would guess that from clicking the 1st install
dialog box to closing firefox consumed no more than 5-6 seconds). After firefox
had closed, talkback kicked in. 

The crash data was sent in TB4388700Z.
(In reply to comment #17)
pretty much the same experience but with switchproxy extension talback TB5167071Z
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3
Flags: blocking-aviary1.1?
*** Bug 290632 has been marked as a duplicate of this bug. ***
Steps from duplicate bug 290632

Reproducible: Always

Steps to Reproduce:
1. Go to
https://addons.update.mozilla.org/themes/moreinfo.php?id=364&application=firefox
2. Try to click 3-4 Times on "Install Now" before first popup appears
3. Click "OK" on the first acknowledge-popup
4. Click "Cancel" on all other ones

Actual Results:  
Firefox Crashes
dveditz, I can't reproduce this with your instructions.  No matter how fast I
click, I only get one install trigger, and a bunch of "download foo.jar"
dialogs.  Did something get fixed elsewhere on this?

Talkback trunk shows nine crashes, none mentioning themes/extensions.  The
stacks all seem to differ.  Its 52nd on the topcrash list with 3, but the stacks
don't match, so I think this is just a generic crash that probably isn't related
to this original issue.

Minusing for now.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
reproducibility here:
click any "install theme" on addons.mozilla.org (retro clasified theme, I
haven't tried other theme category), and firefox is crash (vanish)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513
Fedora/1.0.4-1.3.1 Firefox/1.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711
Firefox/1.0.5

Add TB7643298Y to the list. I was doing something similar to comment #4, clicked
install twice, then clicked OK on the 1st install box and canceled the 2nd. ff
crashed.
Flags: blocking1.8rc1?
Flags: blocking1.8rc1? → blocking1.8rc1-
*** Bug 312646 has been marked as a duplicate of this bug. ***
From bug 312646 comment #0

If you accidentally double-click on an xpi file to install it, then accept the
first install dialogue, the extension window opens.  Then, a second install
dialogue pops up (due to the double-clicking), if you hit cancel, the browser
crashes.

Reproducible: Always

Steps to Reproduce:
1. Pick a random extension
(https://addons.mozilla.org/extensions/moreinfo.php?id=743&application=firefox )
2. click TWICE on the install button
3. Accept the first install dialogue
4. Cancel the second dialog
Actual Results:  
Browser crashes completely.
I suspect that since we now allow an xpinstall to start before a page has
finished loading that this is more likely to happen since I believe the delay
before the dialog is shown is greater while the page is still loading which
could lead to clicking more than one time.
I just tried to reproduce it using the steps in comment #25 and was unable to reproduce. Can anyone else still reproduce this? If so, can you provide steps to reproduce? Thanks.
Reproduced as described in comment 25 with
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

TB data: TB17563127M
Sorry about this but I tested with the latest 1.8.1 branch (e.g. what will become Firefox 2.0). Is anyone able to reproduce with the latest 1.8.1 branch or the trunk?
*** Bug 336769 has been marked as a duplicate of this bug. ***
Summary: FF10 Crash installing themes and extensions [@ nsCOMPtr_base::~nsCOMPtr_base] → FF10 Crash installing themes and extensions (clicking twice on the same install) [@ nsCOMPtr_base::~nsCOMPtr_base]
I just installed Bon Echo, and I got this pretty quickly after trying to install the Nightly Tester Tools.

Talkback ID: TB19091363H
Reed, did you click the link to install twice?
(In reply to comment #32)
> Reed, did you click the link to install twice?

Yeap. The first time I clicked it, I had to add the site to the whitelist. Then I clicked it again a few times, and it wouldn't give me an install dialog. So, I loaded the file directly and it kept repeating an install dialog even if I chose cancel. If I chose install, it wouldn't install that way. I went back to the regular page and chose the install link again, and it prompted me with yet another install dialog that worked finally. After it installed, Bon Echo crashed.
Removing "DUPEME can't reproduce yet". I was on irc with dveditz when he reproduced this.
Whiteboard: DUPEME can't reproduce yet
QA Contact: bugs → extension.manager
OS: Windows XP → All
Hardware: PC → All
moving over to xpinstall since this appears to be an interaction between xpinstall and the confirm install dialog.

dveditz, any chance you have the time to look into this again?
Assignee: dveditz → xpi-engine
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: extension.manager
Version: 1.0 Branch → 1.8 Branch
Same for me the extension menu do not work at all.
The latest version was installed, the older version was deleted, although not from window (add-suppress software) as firefox did not appear in the Program list.

In other words, when i am in the extention menu and click on "option" everything freezes. Can you help?

esteb
Priority: -- → P2
Assignee: xpi-engine → dveditz
Your support would be needed. I desinstalled the latest version of firefox in order to deal with my numerous crashes related to the installation, activation or even desinstallation of extensions. Although i removed and reinstalled firefox, it appears that my extensions are remaining in the memory and that those extensions do not work. When i click on my extension, the overall firefox application freeze.

Please advise, it would be appreciated.

stef
esteb:  I recommend that you uninstall any older versions of Firefox (and completely delete your installation directories).  Then install Firefox 2.0 (http://www.mozilla.com/en-US/firefox/), but do no launch after install.  Instead run your firefox.exe in the Firefox 2.0 install directory with the -P flag (firefox.exe -P).  This should open the profile manager...and I recommend that you create a new profile and start using that instead of the "default" profile.  You can also just delete the default profile (if you don't mind losing all of your settings, bookmarks, saved passwords, etc).  Hope that helps.
This is the #10 crash for Firefox 2.0.0.1. Although the nsCOMPtr_base::nsCOMPtr_base crash consists of about three unique crashes, this one makes up about 25% of them. Requesting blocking.
Flags: blocking1.8.1.3?
Summary: FF10 Crash installing themes and extensions (clicking twice on the same install) [@ nsCOMPtr_base::~nsCOMPtr_base] → FF10 Crash installing themes and extensions (clicking twice on the same install) [@nsCOMPtr_base::~nsCOMPtr_base]
Summary: FF10 Crash installing themes and extensions (clicking twice on the same install) [@nsCOMPtr_base::~nsCOMPtr_base] → Crash [@nsCOMPtr_base::~nsCOMPtr_base] installing themes and extensions (clicking twice on the same install)
Attached file OS X Crash Log
I crash every time using the steps from comment 20. The only addition I would have is that in 2.0.0.3, I had to wait for the download to finish before the crash occurred. Attached is a crash log from my most recent crash.

This crash is currently number 6 for 2.0.0.3.
This crash also appears in talkback with the 0x003a0043 stack signature. Combining those two signatures makes it *the* topcrash for 2.0.0.3 so far.
Summary: Crash [@nsCOMPtr_base::~nsCOMPtr_base] installing themes and extensions (clicking twice on the same install) → Crash [@nsCOMPtr_base::~nsCOMPtr_base] [@ 0x003a0043] installing themes and extensions (clicking twice on the same install)
Flags: blocking1.8.1.4? → wanted1.8.1.x+
Flags: blocking1.9?
fwiw, with my debug trunk windows xp build, I can reproduce the crash following the steps in comment #20.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070504 Minefield/3.0a5pre

here's one example of a stack:

 	72742f73()	
>	xpinstal.dll!nsCOMPtr<nsIXPIListener>::~nsCOMPtr<nsIXPIListener>()  Line 584	C++
 	xpinstal.dll!nsInstallInfo::~nsInstallInfo()  Line 231 + 0x37 bytes	C++
 	xpinstal.dll!nsInstallInfo::`scalar deleting destructor'()  + 0xf bytes	C++
 	xpinstal.dll!RunChromeInstallOnThread(void * data=0x06a3b0c0)  Line 684 + 0x20 bytes	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x06abeeb0)  Line 436 + 0xf bytes	C
 	nspr4.dll!pr_root(void * arg=0x06abeeb0)  Line 122 + 0xf bytes	C
 	msvcr80d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
 	msvcr80d.dll!_threadstartex(void * ptd=0x06aea2b8)  Line 331	C
 	kernel32.dll!7c80b683() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
I gave this a quick try on the branch using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4pre) Gecko/2007050104 BonEcho/2.0.0.4pre, and I was able to crash too. But my stack was different-> nsHTMLEditRules::QueryInterface() 1bf93f27. TB Incident ID 31941055.
early 2.0.0.4 data shows
1 	nsCOMPtr_base::nsCOMPtr_base 	16.7% 	2103 			2103 	4	198	1901
2 	0x00000000 	6.95% 	876 	193750 	108880 	876 	19		857
3 	ntdll.dll 	5.70% 	718 		105752 	718 			718
4 	NPSWF32.dll 	1.96% 	248 	284173 	200511 	248 			248
5 	npdivx32.dll 	1.49% 	188 			188 			188

but for some reason queries for nsCOMPtr_base::nsCOMPtr_base to check out the details of if this is still the theme related carsh are returning zero reports.

jay, any ideas on what's up with the queries?
(In reply to comment #46)
> jay, any ideas on what's up with the queries?

What's up is that the "~" is getting dropped somewhere along the way to generating the report, and if you want to get the query right you need to add it back in.
Couldn't find relevant breakpad reports on trunk. If this is reproducable on trunk, please re-nominate.
Flags: blocking1.9?
Whiteboard: [wanted-1.9]
This is still reproducable, using current trunk build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007083005 Minefield/3.0a8pre

http://crash-stats.mozilla.com/report/index/c7bb7f05-57d5-11dc-928e-001a4bd43e5c
0  	@0x0  	
1 	nsProxyObjectCallInfo::~nsProxyObjectCallInfo() 	mozilla/xpcom/proxy/src/nsProxyEvent.cpp:152
2 	nsProxyObjectCallInfo::`vector deleting destructor'(unsigned int) 	
3 	mozJSSubScriptLoader::Release() 	mozilla/intl/locale/src/nsLocale.cpp:55
4 	nsRefPtr<nsPluginStreamInfo>::~nsRefPtr<nsPluginStreamInfo>() 	nsAutoPtr.h:956
5 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:503
6 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
7 	nsBaseAppShell::Run() 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
8 	nsAppStartup::Run() 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:170
9 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3069
10 	main 	mozilla/browser/app/nsBrowserApp.cpp:153
11 	WinMain 	mozilla/browser/app/nsBrowserApp.cpp:166
12 	__tmainCRTStartup 	crtexe.c:589
13 	BaseProcessStart 	
Flags: blocking1.9?
(In reply to comment #50)
> This is still reproducable, using current trunk build:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007083005
> Minefield/3.0a8pre

That appears to be a completely different stack to the rest in the bug and I suspect something different. It doesn't even look xpinstall related.
I can assure you that I followed the steps to reproduce, double-clicking on an extension link, clicking on the "Install" button on the first Software Installation  dialog and then clicking on the "Cancel" button on the second Software Installation dialog. This is really crashing 100% of the time for me.

Fwiw, here are some more crash reports:
http://crash-stats.mozilla.com/report/index/ab9b8a8a-57d7-11dc-91bd-001a4bd43e5c
http://crash-stats.mozilla.com/report/index/be98a2f8-57d7-11dc-ac5d-001a4bd43ed6
http://crash-stats.mozilla.com/report/index/cb3b6175-57d7-11dc-b73e-001a4bd46e84
I'm sure you did follow the steps, but either those stacks are bogus or they are for a different crash that just happens to be triggered by the same STR.

Either way I seem to remember agreeing to look at this but it won't be till after M8
Assignee: dveditz → nobody
QA Contact: xpi-engine
Target Milestone: --- → mozilla1.9 M9
Version: 1.8 Branch → Trunk
Assignee: nobody → dtownsend
One contributing reason for low/no crash reports might also be the few themes are available for fx3 alphas and the trunk, and I suspect installing themes is just not in the usage pattern for the kinds of testers we are attracting to early alphas and betas.  I'd be skeptical about the crash being fixed unless we could point to some changes that might have resolved the problem.
I followed steps to reproduce from comment 4 on a random extension and crashed with bp-3a2a2f7d-57db-11dc-946f-001a4bd43e5c

It is perhaps worth adding that after I confirmed the first dialog, the extension appeared to install multiple times (progress bar was starting from zero many times) and the crash happened after the installations ceased.

The information about firefox needing a restart never appeared because minefield crashed at exactly this instant.
I can reliably crash in debug build. My knowledge of mozilla internals is limited, but this is what I see in debugger:

As soon as installer finishes, there's a large number of these:
ASSERTION: nsCryptoHash not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()'

And similars for nsStandardURL, nsChromeRegistry and others. They are all triggered from xpinstall thread - they don't like it there.

And then, I close the remaining install window and there's the crash. I found two possible stacks:

When destructing nsInstallInfo. This is because it's trying to destruct nsInstallInfo::mListener but it's a dangling pointer, pointing to freed memory. Similarly, nsInstallInfo::mManifestURL is another dangling pointer and would crash next.

Second possibility: when destructing  CertReader it can die because its mObserver is, similarly, a pointer to freed memory.

It's possible that my interpretation is wrong.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [wanted-1.9]
Attached patch patch rev 1Splinter Review
Ultimately this is a mismatched AddRef/Release problem.

When we start the download process we create an nsXPInstallManager. Do it twice and you get two of them. They AddRef themselves and register for the xpinstall observer topic upon creation.

When you accept the first install it opens the EM which then kicks off the install process by notifying all observers of the xpinstall observer topic. This tells both nsXPInstallManagers to start downloading (even the one that hasn't requested confirmation yet).

Then you cancel the second dialog, which releases itself.

Later the second nsXPInstallManager completes its download, installs, then shuts down, releasing itself (a point it should never get to) leaving its reference count 1 too low.

Then its only a matter of time before the last nsCOMPtr pointing to the nsXPInstallManager attempts to release and crashes, turns out to be the nsInstallInfo which had a reference to the nsXPInstallManager as mListener.

This patch makes the nsXPInstallManager register for the xpinstall topic only when its actually ready to start downloading, i.e. after the download has been confirmed. nsXPInstallManager already covers itself from seeing the open event twice.
Attachment #282570 - Flags: review?(dveditz)
Been thinking on this a little more and I think the whole process of using observer notifications to start and stop nsXPInstallManager is probably not the best mechanism. However I think that's something best left for another time. This patch is fairly simple, effective and should be applicable to the branch as well.
XPInstall was not supposed to be listening to global notifications, the nsXPInstallManager was created to explicitly manage one install and successfully cooperate with other concurrent installs (there's a global nsSoftwareUpdate queue each manager feeds into so actual install activity happens one at a time).

The observer interface was used because it was a handy, simple, frozen interface, but the progress dialog was supposed to directly call the manager handed to it when the dialog was opened. The obsolete xpistatus.js does it correctly and safely:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/xpinstall/content/xpistatus.js&rev=1.4&mark=145,148#122
Here's an alternate approach that reflects the way nsXPInstallManager was intended to be used. Not sure I've gotten the subtleties of the extension manager end right, but it does at least run and install things.

because of the interface change this is hard to land on the 1.8 branch. For that we can go with your patch since it should eliminate the crashing. What do you think?
Attachment #282883 - Flags: review?
Comment on attachment 282570 [details] [diff] [review]
patch rev 1

Is the AddObserver in InitManagerWithHashes() necessary? In that case we explicitly call our own Observe() and don't need an external caller. Do we need it because we try to remove the observer at shutdown? Doesn't seem like that would be a fatal error.

Other than that, this stops the crash, r/sr=dveditz

Let's get this trunk-tested so we can add this to the branch. But eventually I'd prefer going with something like my patch on the trunk.
Attachment #282570 - Flags: superreview+
Attachment #282570 - Flags: review?(dveditz)
Attachment #282570 - Flags: review+
(In reply to comment #61)
> (From update of attachment 282570 [details] [diff] [review])
> Is the AddObserver in InitManagerWithHashes() necessary? In that case we
> explicitly call our own Observe() and don't need an external caller. Do we need
> it because we try to remove the observer at shutdown? Doesn't seem like that
> would be a fatal error.

It is necessary so the manager will listen for the close events to cancel the download which we send when going offline or quitting the app. Checked this in on trunk. Don't know whether you want to close this as fixed then track the interface changes in a new bug?

(In reply to comment #60)
> because of the interface change this is hard to land on the 1.8 branch. For
> that we can go with your patch since it should eliminate the crashing. What do
> you think?

This is pretty much the way I was thinking of going for a trunk only patch. I think we also want to be storing the manager in the ItemDownloadTransaction so that we can handle cancelling the download properly. I can take a closer look tomorrow though.
Attachment #282570 - Attachment description: patch rev 1 → patch rev 1 [checked in on trunk]
Comment on attachment 282570 [details] [diff] [review]
patch rev 1

(In reply to comment #62)
> It is necessary so the manager will listen for the close events to cancel
> the download which we send when going offline or quitting the app.

Oh, right :-( -- yeah you'll have to save the manager for later cancelling.

Let's get this top-crash fix into the branch, too.
Attachment #282570 - Flags: approval1.8.1.8?
Attachment #282883 - Attachment description: alternate approach → alternate approach (partial--doesn't handle cancel on quit)
Attachment #282883 - Flags: review? → review-
I've spun off bug 398080 to cover reworking this. As a crash bug let's call this one FIXED with your check-in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment on attachment 282570 [details] [diff] [review]
patch rev 1

approved for 1.8.1.8, a=dveditz for release-drivers
Attachment #282570 - Flags: approval1.8.1.8? → approval1.8.1.8+
Flags: blocking1.8.1.8+
Keywords: fixed1.8.1.8
Attachment #282570 - Attachment description: patch rev 1 [checked in on trunk] → patch rev 1
Attachment #282883 - Attachment is obsolete: true
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100104 Minefield/3.0a9pre

Thanks for fixing this!
Status: RESOLVED → VERIFIED
Verified on branch as well using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8pre) Gecko/20071002 BonEcho/2.0.0.8pre
Crash Signature: [@nsCOMPtr_base::~nsCOMPtr_base] [@ 0x003a0043]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: