Closed Bug 304351 Opened 20 years ago Closed 19 years ago

browsing away from page that contains scriptable plugin crashes after loading plugin

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 300756

People

(Reporter: mark_boudreau, Unassigned)

Details

(Keywords: crash)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 SeaMonkey/1.0a Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 SeaMonkey/1.0a After loading a scriptable plugin object in a page that includes it using the <embed> tag, any attempts to browse away from the page will cause the browser to crash. It may be right as you click a link on the page or enter a URL, or it may be as you close the window after browsing other sites for a period of time. I noticed this on plugins that I made, but tried to include a link on the provided NPRuntime sample code and this also causes a problem. Reproducible: Always Steps to Reproduce: 1. Load a page that has an embedded scriptable plugin (npXXX.dll) 2. Follow a link on that page or navigate away from it by typing in a URL in the address bar 3. If your browser hasn't crashed yet, attempt to close the browser. Actual Results: The browser crashes. Expected Results: Follow the link to the proper page, or close normally if you were attempting to close the browser. nspr4.dll is on the top of the call stack. the stack follows: > nspr4.dll!60f46899() gkplugin.dll!604f22f7() gkplugin.dll!60502d44() js3250.dll!60dac643() js3250.dll!60d9d513() js3250.dll!60d9cee6() js3250.dll!60d82912() profile.dll!60a23475() ntdll.dll!7c915b4f() seamonkey.exe!004019df() seamonkey.exe!0040194e() seamonkey.exe!00402b93() seamonkey.exe!004074f8() ntdll.dll!7c915b4f() kernel32.dll!7c816d4f() ntdll.dll!7c915b4f() kernel32.dll!7c8399f3() Output that describes the crash: First-chance exception at 0x60f46899 in seamonkey.exe: 0xC0000005: Access violation writing location 0x00ae1f90. Unhandled exception at 0x60f46899 in seamonkey.exe: 0xC0000005: Access violation writing location 0x00ae1f90.
yeah, we know, but we really don't understand, if you could help us figure out what's going wrong, that'd be great
Assignee: general → nobody
Component: General → Plug-ins
Keywords: crash
Product: Mozilla Application Suite → Core
QA Contact: general → plugins
Whiteboard: DUPEME
Version: unspecified → Trunk
We came across this bug when porting our voice conferencing activex control to a windowless Mozilla plugin, but there is a simple workaround. Just add this line of javascript somewhere after the <embed>: var embed = document.embeds[0]; It doesn't do anything and it shouldn't be required, but for some reason it prevents the crash.
Yeah I am already using that particular code in javascript. I go on and use the embed varible so that I can call native methods written in C [embed.methodName()] Thanks for the suggestion though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
After a static build of seamonkey, loading the NPRuntime plugin and trying to navigate away from it results in this call stack: > js3250.dll!js_GetSlotThreadSafe(JSContext * cx=0x00000000, JSObject * obj=0x03bf6180, unsigned long slot=2) Line 572 + 0x3 js3250.dll!JS_SetPrivate(JSContext * cx=0x00000000, JSObject * obj=0x03bf6180, void * data=0x00000000) Line 2157 + 0xe7 mozilla.exe!NPObjWrapperPluginDestroyedCallback(PLDHashTable * table=0x01b62224, PLDHashEntryHdr * hdr=0x02e90d10, unsigned int number=0, void * arg=0x02e78744) Line 1311 + 0x13 xpcom_core.dll!PL_DHashTableEnumerate(PLDHashTable * table=0x01b62224, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor=0x0065e430, void * arg=0x02e78744) Line 619 + 0x19 mozilla.exe!nsJSNPRuntime::OnPluginDestroy(_NPP * npp=0x02e78744) Line 1330 + 0x13 mozilla.exe!ns4xPluginInstance::Stop() Line 938 + 0xc mozilla.exe!StopPluginInstance(PresShell * aShell=0x03bb5838, nsIContent * aContent=0x03bd2610) Line 6551 mozilla.exe!PresShell::EnumeratePlugins(nsIDOMDocument * aDocument=0x03ae6e70, const nsString & aPluginTag={...}, void (PresShell *, nsIContent *)* aCallback=0x007afa90) Line 7226 + 0x10 mozilla.exe!PresShell::Freeze() Line 6577 + 0x26 mozilla.exe!DocumentViewerImpl::Destroy() Line 1336 mozilla.exe!DocumentViewerImpl::Show() Line 1710 mozilla.exe!nsPresContext::EnsureVisible(int aUnsuppressFocus=0) Line 1256 mozilla.exe!PresShell::UnsuppressAndInvalidate() Line 5026 + 0xd mozilla.exe!PresShell::UnsuppressPainting() Line 5075 mozilla.exe!DocumentViewerImpl::LoadComplete(unsigned int aStatus=0) Line 1044 mozilla.exe!nsDocShell::EndPageLoad(nsIWebProgress * aProgress=0x03aaafac, nsIChannel * aChannel=0x03c6a118, unsigned int aStatus=0) Line 4639 mozilla.exe!nsWebShell::EndPageLoad(nsIWebProgress * aProgress=0x03aaafac, nsIChannel * channel=0x03c6a118, unsigned int aStatus=0) Line 665 mozilla.exe!nsDocShell::OnStateChange(nsIWebProgress * aProgress=0x03aaafac, nsIRequest * aRequest=0x03c6a118, unsigned int aStateFlags=131088, unsigned int aStatus=0) Line 4565 mozilla.exe!nsDocLoader::FireOnStateChange(nsIWebProgress * aProgress=0x03aaafac, nsIRequest * aRequest=0x03c6a118, int aStateFlags=131088, unsigned int aStatus=0) Line 1200 mozilla.exe!nsDocLoader::doStopDocumentLoad(nsIRequest * request=0x03c6a118, unsigned int aStatus=0) Line 833 mozilla.exe!nsDocLoader::DocLoaderIsEmpty() Line 730 mozilla.exe!nsDocLoader::OnStopRequest(nsIRequest * aRequest=0x03c86d00, nsISupports * aCtxt=0x00000000, unsigned int aStatus=0) Line 654 mozilla.exe!nsLoadGroup::RemoveRequest(nsIRequest * request=0x03c86d00, nsISupports * ctxt=0x00000000, unsigned int aStatus=0) Line 732 + 0x2c mozilla.exe!nsDocument::UnblockOnload() Line 4920 mozilla.exe!DestroyImagePLEvent(PLEvent * aEvent=0x03cbfb88) Line 659 xpcom_core.dll!PL_DestroyEvent(PLEvent * self=0x03cbfb88) Line 724 + 0xa xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x03cbfb88) Line 696 + 0x9 xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x027a4ad8) Line 620 + 0x9 xpcom_core.dll!_md_EventReceiverProc(HWND__ * hwnd=0x002001ee, unsigned int uMsg=49699, unsigned int wParam=0, long lParam=41568984) Line 1405 + 0x9 user32.dll!77d48734() user32.dll!77d48816() user32.dll!77d489cd() user32.dll!77d49402() user32.dll!77d48a10() mozilla.exe!nsAppShell::Run() Line 135 mozilla.exe!nsAppStartup::Run() Line 208 mozilla.exe!main1(int argc=2, char * * argv=0x01e49b78, nsISupports * nativeApp=0x02787290) Line 1272 + 0x20 mozilla.exe!main(int argc=2, char * * argv=0x01e49b78) Line 1763 + 0x25 mozilla.exe!mainCRTStartup() Line 398 + 0x11 kernel32.dll!7c816d4f() kernel32.dll!7c8399f3()
brendan/johnny, any ideas that mark can try?
My bet would be that this was fixed on the 1.8 branch on 2005-08-22. Could you please test with a firefox branch build from 2005-08-23 or later? I.e. download a build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ and test again. If it's fixed there, this is a dupe of bug 300756.
The firefox 1.5b1 build (from the link you provided) seems to get rid of this error. However, it doesn't seem to be fixed in later versions (should this happen?). I pulled more recent source from mozilla and built firefox 1.6a1, and when trying to navigate away from the plugin, got the following assertion: ASSERTION: dangling entry->mJSObj JSPrivate because we can't find cx: 'Error', file C:/.../mozilla/modules/plugin/base/src/nsJSNPRuntime.cpp, line 1351 Choosing to ignore this assertion leads to normal browser behavior, except when you attempt to close the browser. The browser then crashes with the following call stack (which looks similar to my original post). > nspr4.dll!_PR_MD_ATOMIC_DECREMENT(int * val=0x03ac20e8) Line 733 nspr4.dll!PR_AtomicDecrement(int * val=0x03ac20e8) Line 310 + 0x9 gkplugin.dll!_releaseobject(NPObject * npobj=0x03ac20e4) Line 1520 + 0xd gkplugin.dll!NPObjWrapper_Finalize(JSContext * cx=0x03216210, JSObject * obj=0x02b46f08) Line 1195 + 0x9 js3250.dll!js_FinalizeObject(JSContext * cx=0x03216210, JSObject * obj=0x02b46f08) Line 2074 + 0x60 js3250.dll!js_GC(JSContext * cx=0x03216210, unsigned int gcflags=0) Line 1839 + 0xb js3250.dll!js_ForceGC(JSContext * cx=0x03216210, unsigned int gcflags=0) Line 1510 + 0xd js3250.dll!JS_GC(JSContext * cx=0x03216210) Line 1848 + 0xb firefox.exe!nsXREDirProvider::DoShutdown() Line 635 + 0xa firefox.exe!ScopedXPCOMStartup::~ScopedXPCOMStartup() Line 550 firefox.exe!XRE_main(int argc=1, char * * argv=0x003e6f98, const nsXREAppData * aAppData=0x00422090) Line 2349 firefox.exe!main(int argc=1, char * * argv=0x003e6f98) Line 61 + 0x12 firefox.exe!mainCRTStartup() Line 398 + 0x11 kernel32.dll!7c816d4f() kernel32.dll!7c8399f3()
It seems that the difference between the two versions of firefox that I tested is that one was a debug version, and the other was not. 1.5b1 was a release version taken from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ 1.6a1 was a debug version that I built from source code checked out with CVS. Perhaps the error is still in 1.5b1, just not showing because there are no debug assertions that are failing?
/me thinks this is a dupe of bug 300756. Marking so, please reopen if that's not the case (i.e. if this is still happening). *** This bug has been marked as a duplicate of 300756 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
What seems to be happening, if this is the same as the bug I have is that the if you store the embed result from getElementById, in javascript, and the embed is destroyed, any attempts to access properties on that stored value will crash the browser. ie: var embed = getElementById('my_plugin') do something to cause the plugin to be destroyed ie: embed.style.display = "none" if you have the plugin log level up enough, you can see the destroy messages then try embed.memberFun() and your browser will crash
I don't think that's the same bug; and note that this one is fixed... you should file a new bug on that
Whiteboard: DUPEME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.