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.
-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?
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: nspr4!PR_FindSymbol nspr4!PR_FindFunctionSymbol xul!mozilla::plugins::PluginModuleChild::Init xul!mozilla::plugins::PluginProcessChild::Init xul!XRE_InitChildProcess plugin_container!NS_internal_main plugin_container!wmain plugin_container!__tmainCRTStartup plugin_container!wmainCRTStartup kernel32!RegisterWaitForInputIdle
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?
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.
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: bp-ced73422-36b3-47c6-a631-d81f12120816 Enabling click-to-play made the difference, but I'm checking now if this is reproducible.
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`