432743 - Applet + plugin causing FF to crash [@ JS_SetPrivate - NPObjWrapperPluginDestroyedCallback]

Status: RESOLVED DUPLICATE of bug 421217

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Wilco Bauwer (MSFT)]

Given the following function:

    function foo() {
        var a = document.createElement('applet');
        document.body.appendChild(a);
        alert(a.id);
    }

FF seems to crash when invoking this function from a plugin at least 2 times, or invoking it from JS first and then invoke it once from a plugin. The callstack at the time of the crash is:

#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x172b87fc in RaiseExceptionObject (exceptionObject=0x15638400) at seh-unwind.cpp:534
#4  0x172b8863 in SEHRaiseException (pthrCurrent=0x2421c00, lpExceptionPointers=0xbfffba84, signal_code=0) at seh-unwind.cpp:596
#5  0x172b91bc in PAL_DispatchException (pContext=0xbfffbaf8, pExRecord=0xbfffbaa8) at ../../machexception.cpp:407
#6  0x172c8953 in CorUnix::CSharedMemoryFileLockController::ReleaseController () at shmfilelockmgr.hpp:85
#7  0x2ed956ba in ?? ()
#8  0x2ed8a9d3 in ?? ()
#9  0x2ed8aaaa in ?? ()
#10 0x2ed8821f in ?? ()
#11 0x9abd8f8a in jio_snprintf ()
#12 0x9abd8cd8 in jio_snprintf ()
#13 0x9abe858b in JVM_MonitorWait ()
#14 0x9abe80cb in JVM_MonitorWait ()
#15 0x1ab5efc1 in Java_java_lang_Object_wait_redirect ()
#16 0x1ab605c8 in Java_java_lang_Object_wait_redirect ()
#17 0x1ab59d7e in Java_java_lang_Object_wait_redirect ()
#18 0x1ab7116a in ShowClassInfo ()
#19 0x1ab70f84 in ShowClassInfo ()
#20 0x1ab75007 in JEPSizeJavaApplet ()
#21 0x1ab107e0 in JEPSizeJavaApplet ()
#22 0x1ab143fe in MRJContext::synchronizeVisibility ()
#23 0x1ab146fd in MRJContext::synchronizeClipping ()
#24 0x1ab156e6 in MRJContext::setWindow ()
#25 0x1ab19168 in MRJPluginInstance::SetWindow ()
#26 0x011fe3d9 in XRE_GetFileFromPath ()
#27 0x01200e10 in XRE_GetFileFromPath ()
#28 0x01203c64 in XRE_GetFileFromPath ()
#29 0x0132c781 in XRE_GetFileFromPath ()
#30 0x0132e414 in XRE_GetFileFromPath ()
#31 0x01459218 in XRE_GetFileFromPath ()
#32 0x01462bf4 in XRE_GetFileFromPath ()
#33 0x01056e5c in XRE_GetFileFromPath ()
#34 0x0024a376 in JSLL_MinInt ()
#35 0x0024c572 in js_LookupProperty ()
#36 0x0024c7a8 in js_LookupProperty ()
#37 0x00236d7f in JS_CompareValues ()
#38 0x0023f840 in js_Invoke ()
#39 0x0023ef96 in js_FreeStack ()
#40 0x002093e1 in JS_CallFunctionValue ()
#41 0x016b470a in XRE_GetFileFromPath ()
#42 0x016b48b1 in XRE_GetFileFromPath ()
#43 0x0169db70 in XRE_GetFileFromPath ()
#44 0x1c4c0c2d in NPWrapper::InvokeObjectMethod (pObject=0x1af98534, pidName=0x6f6634, pvarArgs=0xbfffd0d4, nArgCount=2, pResult=0xbfffd130) at .../NPWrapper.cpp:140

This repros on the Mac only, on both FF2 and FF3. Doing the same thing for different type of elements (e.g. a div instead of an applet) works fine. Invoking "foo" multiple times from JS only also works fine.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Could you attach a sample Java applet (with source) and the HTML from
which it's loaded?

Comment 2

[Wilco Bauwer (MSFT)]

Attachment: Repro

Extract + run HTML file from FF. It should first display an alert and then try to invoke the JS function "test" twice. This is where things seem to crash for us.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

OK, so it's a Silverlight applet that you're testing with.

I need a downloadable installer for Silverlight (the "Click to
Install" business doesn't work).  But I can no longer find one at
http://www.silverlight.net.

Also, as far as I can tell your testcase doesn't include any source
code for the included Silverlight applet.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb trace from build with debug symbols

I figured out how to download a current Silverlight installer -- load
your testcase in Safari.  (Apparently the latest version is still
Silverlight 2.0 Beta 1.)

And I'm	able to reproduce your crashes ... or something like them.

This is the log of a gdb session made with a build containing debug
symbols (equivalent to yesterday's Minefield trunk nightly).  For
complicated reasons, gdb and crashreporterd often misreport
Mozilla-specific symbols in traces made from Mozilla.org builds whose
symbols have been stripped (as they have been from all downloadable
"installers").  So the reason my log is different from yours is
probably because most of the symbols in yours have been inaccurately
reported.

My log has two parts:

First I broke on malloc_printf (which prints many copies of the
following error to stdout/stderr) and did a stack trace.

  *** mmap(size=4229926912) failed (error code=12)
  *** error: can't allocate region
  *** set a breakpoint in malloc_error_break to debug

Then I closed the browser window and crashed -- at which point I did
another stack trace.

The same wierd malloc error (resulting from trying to allocate an
impossibly large "region") is one of the symptoms of bug 431902.  So
these two bugs are almost certainly related.

I'll be working on them both.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I crash in today's Minefield nightly on Windows using the same STR as
on OS X:

1) Load the testcase and let it finish.

2) Close the browser window into which the testcase was loaded ->
   crash.

Here are a couple of Breakpad reports of my crashes on Windows:

bp-4c46d428-22c9-11dd-898b-001cc45a2c28
bp-18402e85-22c9-11dd-8e50-001321b13766

For comparison, here's a Breakpad report of a crash on OS X:

bp-c582ab97-22c9-11dd-aa74-001cc45a2c28

For what it's worth, here are three crash bugs that all have to do
with a malformed APPLET/OBJECT tag (as this bug may also).  All these
bugs have been resolved ... but they might still be relevant:

bug 189485
bug 314278
bug 345627

Comment 6

[Steven Michaud [:smichaud] (Retired)]

This bug's testcase doesn't crash Firefox 2.0.0.14 on either OS X or
Windows.

Comment 7

[timeless]

Signature	JS_SetPrivate
UUID	c582ab97-22c9-11dd-aa74-001cc45a2c28
Time	2008-05-15 14:56:20-07:00
Uptime	32
Product	Firefox
Version	3.0pre
Build ID	2008051504
OS	Mac OS X
OS Version	10.5.2 9C7010
CPU	x86
CPU Info	GenuineIntel family 6 model 7 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0xa11c8
Comments	
Crashing Thread
Frame 	Module 	Signature 	Source
0 	libmozjs.dylib 	JS_SetPrivate 	mozilla/js/src/jslong.c:2888
1 	XUL 	NPObjWrapperPluginDestroyedCallback 	mozilla/modules/plugin/base/src/nsJSNPRuntime.cpp:1805
2 	XUL 	PL_DHashTableEnumerate 	pldhash.c:724
3 	XUL 	nsJSNPRuntime::OnPluginDestroy 	mozilla/modules/plugin/base/src/nsJSNPRuntime.cpp:1846
4 	XUL 	ns4xPluginInstance::Stop 	mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:960
5 	XUL 	DoStopPlugin 	mozilla/layout/generic/nsObjectFrame.cpp:1840
6 	XUL 	nsStopPluginRunnable::Run 	mozilla/layout/generic/nsObjectFrame.cpp:1890
7 	XUL 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
8 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180 

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I have a patch for bug 431902 that gets rid of this bug's "can't
allocate region" messages.  But it doesn't fix this bug's crash.
See bug 431902 comment #13.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The crash signature is identical to the ones given on bug 421217. I've tested the testcase with Silverlight 1.0 and Silverlight 2.0 beta installed. The crash only occurs with the latter one. So this bug is a dupe of bug 421217.