Closed Bug 545312 Opened 11 years ago Closed 11 years ago
Flash game fails to load with OOPP enabled
Shockwave Flash 10.0 r42 Hangs a lot in loading w/ OOPP enabled (could be my imagination but other tabs seem a lot slower to load while it is active too), but never gets beyond loading. Disabling OOPP causes it to load perfectly. Does seem to contact a bunch of remote servers, and this seems slower, don't know if that's related.
x86 linux as noted in the filing, but more specifically, Ubuntu Karmic. BTW, most flash seems to take up a lot more CPU than it used to, for example, playing an audio sample on google voice maxes out one core even after the sample is done playing, until I close the google voice tab. Shame they don't offer <audio> tag except in their iphone version.
On my machine, loading the applet doesn't "hang" in the sense of locking up; firefox and flash stay responsive throughout. However, the applet stops painting after a short period of time. Sometimes it gets further along than other times; once it loaded to the point where a button was painted, and mousing over the button worked. Log data that looks relevant to gfx nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1 nsPluginNativeWindowGtk2: call SetWindow with xid=0x4e001af 371206144[7fb009f12040]: NPError mozilla::plugins::PluginInstanceParent::NPP_SetWindow(const NPWindow*) (aWindow=7faff7931988) [time:1265845702655162][PPluginInstanceParent] Sending Msg_NPP_SetWindow() [time:1265845702655267][PPluginInstanceChild] Received Msg_NPP_SetWindow() -1429632752[b7ded0]: virtual bool mozilla::plugins::PluginInstanceChild::AnswerNPP_SetWindow(const mozilla::plugins::NPRemoteWindow&, NPError*) (aWindow=<window: 0x4e001af, x: 0, y: 0, width: 1920, height: 906>) -1429632752[b7ded0]: NPError mozilla::plugins::child::_getvalue(NPP_t*, NPNVariable, void*) [time:1265845702655299][PPluginModuleChild] Sending Msg_NPN_GetValue_WithBoolReturn() [time:1265845702655350][PPluginModuleParent] Received Msg_NPN_GetValue_WithBoolReturn() [time:1265845702655359][PPluginModuleParent] Sending reply Reply_NPN_GetValue_WithBoolReturn() [time:1265845702655427][PPluginModuleChild] Received reply Reply_NPN_GetValue_WithBoolReturn() (<unknown>:28898): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed The assertion failure is tracked in bug 539138, but I'm not sure it's relevant. Just before the applet stops repainting, I see [time:1265846332124711][PBrowserStreamChild] Received Msg_NPP_Write() -1429632752[b7ded0]: virtual bool mozilla::plugins::BrowserStreamChild::AnswerNPP_Write(const int32_t&, const mozilla::plugins::Buffer&, int32_t*) (offset=753664, data.length=11950) [time:1265846332124866][PBrowserStreamChild] Sending reply Reply_NPP_Write() [time:1265846332124973][PBrowserStreamParent] Received reply Reply_NPP_Write() 371206144[7fb009f12040]: NPError mozilla::plugins::PluginInstanceParent::NPP_DestroyStream(NPStream*, NPReason) (stream=7faff95f6648, reason=0) [time:1265846332125032][PBrowserStreamParent] Sending Msg___delete__() [time:1265846332125105][PBrowserStreamChild] Received Msg___delete__() -1429632752[b7ded0]: void mozilla::plugins::BrowserStreamChild::NPP_DestroyStream(NPError) (reason=0) [time:1265846332125138][PBrowserStreamChild] Sending reply Reply___delete__() [time:1265846332125249][PBrowserStreamParent] Received reply Reply___delete__() --DOMWINDOW == 11 (0x7faffabb7858) [serial = 24] [outer = 0x7faffdb15000] [url = http://www.freewebarcade2.info/media/ricochet-kills.swf] I don't see any other information in the log that indicates what might be failing. Two weak hypotheses: (i) the stream dtor is behaving differently than for IPP, and flash never thinks the applet has finished downloading. (ii) flash is making a platform API call that throws or returns an error, and the applet is dying because of that (like an uncaught exception in JS). I can test (i) without too much pain, (ii) is harder.
The bug is gone in http://hg.mozilla.org/projects/electrolysis/rev/482029a3e147, but manifests in http://hg.mozilla.org/projects/electrolysis/rev/1be234301318, according to Karl. So removing XPCOM from plugin processes definitely caused this.
Pushed http://hg.mozilla.org/projects/electrolysis/rev/e5c03e24fe58 This ended up being the underlying issue as in bug 544882, so I'm going to DUP when I really mean RESOLVED SUBSUMED.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 544882
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.