15 years ago
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.
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
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
*** 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.
*** 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:22.214.171.124) Gecko/20060111 Firefox/126.96.36.199 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
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
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 188.8.131.52. Although the nsCOMPtr_base::nsCOMPtr_base crash consists of about three unique crashes, this one makes up about 25% of them. Requesting blocking.
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)
I crash every time using the steps from comment 20. The only addition I would have is that in 184.108.40.206, 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 220.127.116.11.
This crash also appears in talkback with the 0x003a0043 stack signature. Combining those two signatures makes it *the* topcrash for 18.104.22.168 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)
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:22.214.171.124pre) Gecko/2007050104 BonEcho/126.96.36.199pre, and I was able to crash too. But my stack was different-> nsHTMLEditRules::QueryInterface() 1bf93f27. TB Incident ID 31941055.
early 188.8.131.52 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.
Duplicate of this bug: 391322
Couldn't find relevant breakpad reports on trunk. If this is reproducable on trunk, please re-nominate.
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
(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
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.
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.
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.
(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: approval184.108.40.206?
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
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 282570 [details] [diff] [review] patch rev 1 approved for 220.127.116.11, a=dveditz for release-drivers
Attachment #282570 - Flags: approval18.104.22.168? → approval22.214.171.124+
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:126.96.36.199pre) Gecko/20071002 BonEcho/188.8.131.52pre
Crash Signature: [@nsCOMPtr_base::~nsCOMPtr_base] [@ 0x003a0043]
You need to log in before you can comment on or make changes to this bug.