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)
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
Comment 2•19 years ago
|
||
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.
Reporter | ||
Comment 3•19 years ago
|
||
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.
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 4•19 years ago
|
||
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()
Comment 5•19 years ago
|
||
brendan/johnny, any ideas that mark can try?
Comment 6•19 years ago
|
||
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.
Reporter | ||
Comment 7•19 years ago
|
||
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()
Reporter | ||
Comment 8•19 years ago
|
||
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?
Comment 9•19 years ago
|
||
/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
Comment 10•19 years ago
|
||
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
Comment 11•19 years ago
|
||
I don't think that's the same bug; and note that this one is fixed... you should file a new bug on that
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•