If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

plugin-container.exe crashed once after Flash updated in the background




5 years ago
5 years ago


(Reporter: neil@parkwaycc.co.uk, Unassigned)


({crash, qawanted})

Firefox Tracking Flags

(Not tracked)




5 years ago
Adobe updated Flash for me while the browser was open, but plugin-container got confused because it was still trying to load the old version. After it aborted, the browser then restarted plugin-container using the right version of Flash. I don't know what would have happened if I had been using a release build.

Comment 1

5 years ago
-central self-build, I presume? We are intentionally loading the new version of Flash while the old one is still present (as long as both are OOPP) so that we start using the new one right away while there may still be instances of the old version present.

No stack or minidump, I guess? Any interesting debug spew?

Comment 2

5 years ago
ASSERTION: plugin file ain't there: 'exists'
ASSERTION: trouble with mPluginFile: 'NS_OK == rv'
ASSERTION: couldn't open shared object: 'mLibrary'
Assertion failure: lib != null

Stack for that final (fatal) assertion:


5 years ago
Severity: normal → critical
Keywords: crash

Comment 3

5 years ago
What version of Flash were you updating from/to? Usually when Firefox is running Flash doesn't delete its old DLL (it cleans up at reboot). But maybe there is a condition where we have already decided to use Flash (via pluginreg) but it's not locked, so if you:

* run Firefox without Flash loaded
* update Flash
* load a page with Flash

Then we might end up in this situation. Can I get someone from QA to play around with my description and try to come up with reliable STR?
Keywords: qawanted


5 years ago
QA Contact: jbecerra
I'm trying to reproduce this by installing an older version of Flash 11.3 on a clean XP VM. While I haven't reproduced the problem yet, I did notice during one of my trials that Flash had been disabled, as shown in about:addons. It may have happened during its auto-update. I re-enabled it and then it displayed the most recent version of Flash.

Comment 5

5 years ago
The plugin-container was originally trying to load NPSWF32_11_3_300_270.dll but NPSWF32_11_3_300_271.dll had already been installed. I'm not sure whether I had used Flash previously in that browsing session; I often watch videos daily, but otherwise I have click-to-play enabled so other objects wouldn't have run, also normally I leave the build running for days at a time because that PC is on the slow side so I only update the build once a week.

It was because NPSWF32_11_3_300_271.dll had a fairly recent timestamp (about an hour or so before the crash) that I realised that Flash had been updated.
I installed 11.3.300.262, enabled click to play, loaded youtube.com, clicked to play a video and I tried getting the context menu to see which version of Flash had been loaded, the plugin area went blank, I reloaded the page and the HTML5 version was loaded. I checked about:crashes right after, and there was a crash instance:


Enabling click-to-play made the difference, but I'm checking now if this is reproducible.

Comment 7

5 years ago
I'm going to dup this to bug 700583 which is tracking this crash signature. Juan, if I may hazard a guess, I think that this probably has nothing to do with CTP, but instead has to do with us stopping the plugin-container after 3 minutes of inactivity. So STR *might* be something like:

* Start with an old Flash
* Load youtube in the browser
* Navigate away to pages which don't use Flash
* wait more than 3 minutes
* Upgrade Flash using the "automatic upgrade" settings. According to Adobe this means running the new Flash installer with the command line options `install_flash_player.exe -install -iv 9`
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 700583
You need to log in before you can comment on or make changes to this bug.