421833 - Crash [@ nsObjectFrame::CallSetWindow] with Java 1.6.0_10 and going back and forward

Status: VERIFIED FIXED

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

Description

[Martijn Wargers (dead)]

See discussion in bug 275783, comment 111 and further.

To reproduce the crash:
- Download the latest Java version (development version, I believe), Java Plug-in 1.6.0_10: http://download.java.net/jdk6/
- Visit the url testcase: https://bugzilla.mozilla.org/attachment.cgi?id=279607
- While that one is still loading the plugin, quickly go back and forward.

Normally, I crash reasonably easy in that way.
I also get a crash very easy with the testcase from bug 404616 ( https://bugzilla.mozilla.org/attachment.cgi?id=289535 ), and then going back and forward in history. I think the same type of crash.

I was hoping this would be fixed with the fix for bug 393845, but apparently, it hasn't.

Breakpad doesn't come up, btw.
Here's a stacktrace of the crash with a debug build:
>	gklayout.dll!nsObjectFrame::CallSetWindow()  Line 874 + 0x44 bytes	C++
 	gklayout.dll!nsObjectFrame::Instantiate(const char * aMimeType=0x043f99e0, nsIURI * aURI=0x068c4328)  Line 1617	C++
 	gklayout.dll!nsObjectLoadingContent::Instantiate(nsIObjectFrame * aFrame=0x0682c1b0, const nsACString_internal & aMIMEType={...}, nsIURI * aURI=0x068c4328)  Line 1635 + 0x1a bytes	C++
 	gklayout.dll!nsObjectLoadingContent::EnsureInstantiation(nsIPluginInstance * * aInstance=0x0012e68c)  Line 724 + 0x22 bytes	C++
 	gklayout.dll!nsHTMLPluginObjElementSH::GetPluginInstance(nsIXPConnectWrappedNative * wrapper=0x064e7b10, nsIPluginInstance * * _result=0x0012e68c)  Line 8815 + 0x1d bytes	C++
 	gklayout.dll!nsHTMLPluginObjElementSH::PostCreate(nsIXPConnectWrappedNative * wrapper=0x064e7b10, JSContext * cx=0x04cb9718, JSObject * obj=0x03ef39a0)  Line 8855 + 0x24 bytes	C++
 	xpc3250.dll!XPCWrappedNative::GetNewOrUsed(XPCCallContext & ccx={...}, nsISupports * Object=0x043f9b28, XPCWrappedNativeScope * Scope=0x0684e488, XPCNativeInterface * Interface=0x049e0128, int isGlobal=0, XPCWrappedNative * * resultWrapper=0x0012e89c)  Line 546 + 0x47 bytes	C++
 	xpc3250.dll!XPCConvert::NativeInterface2JSObject(XPCCallContext & ccx={...}, nsIXPConnectJSObjectHolder * * dest=0x0012e934, nsISupports * src=0x043f9b28, const nsID * iid=0x0012ebc8, JSObject * scope=0x058d34e0, int allowNativeWrapper=1, int isGlobal=0, unsigned int * pErr=0x0012ebb0)  Line 1106 + 0x22 bytes	C++
 	xpc3250.dll!XPCConvert::NativeData2JS(XPCCallContext & ccx={...}, long * d=0x0012ea98, const void * s=0x0012eb20, const nsXPTType & type={...}, const nsID * iid=0x0012ebc8, JSObject * scope=0x058d34e0, unsigned int * pErr=0x0012ebb0)  Line 481 + 0x35 bytes	C++
 	xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD)  Line 2456 + 0x35 bytes	C++
 	xpc3250.dll!XPC_WN_CallMethod(JSContext * cx=0x04cb9718, JSObject * obj=0x058d34e0, unsigned int argc=1, long * argv=0x043d291c, long * vp=0x0012ede4)  Line 1470 + 0xe bytes	C++
 	js3250.dll!js_Invoke(JSContext * cx=0x04cb9718, unsigned int argc=1, long * vp=0x043d2914, unsigned int flags=2048)  Line 1275 + 0x20 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x04cb9718)  Line 4897 + 0x16 bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x04cb9718, unsigned int argc=1, long * vp=0x043d2908, unsigned int flags=2)  Line 1291 + 0x9 bytes	C
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x04cb9718, JSObject * obj=0x07280a80, long fval=93142208, unsigned int flags=0, unsigned int argc=1, long * argv=0x0693e0a0, long * rval=0x0012f628)  Line 1347 + 0x18 bytes	C
 	js3250.dll!JS_CallFunctionValue(JSContext * cx=0x04cb9718, JSObject * obj=0x07280a80, long fval=93142208, unsigned int argc=1, long * argv=0x0693e0a0, long * rval=0x0012f628)  Line 5007 + 0x1f bytes	C
 	gklayout.dll!nsJSContext::CallEventHandler(nsISupports * aTarget=0x067d27e8, void * aScope=0x07280a80, void * aHandler=0x058d3cc0, nsIArray * aargv=0x043f9fcc, nsIVariant * * arv=0x0012f6e0)  Line 1961 + 0x24 bytes	C++
 	gklayout.dll!nsGlobalWindow::RunTimeout(nsTimeout * aTimeout=0x06847310)  Line 7739 + 0xab bytes	C++
 	gklayout.dll!nsGlobalWindow::TimerCallback(nsITimer * aTimer=0x06846c58, void * aClosure=0x06847310)  Line 8073	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 400 + 0xe bytes	C++
 	xpcom_core.dll!nsTimerEvent::Run()  Line 490	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f848)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x012c3ee0, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 151 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 181 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x003ff630, const nsXREAppData * aAppData=0x003fb070)  Line 3154 + 0x25 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x003ff630)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=1, unsigned short * * argv=0x003f9eb0)  Line 87 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Comment 1

[Hermann Schwab]

Latest *released* version of Java is 6u5, released about a week ago.
http://java.sun.com/javase/downloads/index.jsp

Bug 275783 Comment #130 is telling more about 6u10 now in beta.

Comment 2

[Martijn Wargers (dead)]

Hi Kenneth, this is still crashing for me.
Is this a bug in the latest Java plugin or in current Firefox trunk build?

Comment 3

[Kenneth Russell]

I don't have access to bug 404616 and therefore the test case.

I don't see any indication that the bug is in the Java Plug-In in the above stack trace. If the test case crashes with Firefox but not IE, that would be an indication that the bug is more likely on the browser side. It would be most helpful if one of the Mozilla engineers could diagnose the root cause of the crash more completely. We are more than happy to fix anything that appears to be broken on the Java Plug-In side.

Comment 4

[Johnny Stenback (:jst)]

(In reply to comment #3)
> I don't have access to bug 404616 and therefore the test case.

FWIW, you do now :)

Comment 5

[timeless]

You should know that java integrates w/ ie using an activex control, which is not the same code as the npapi plugin. Trying to use ie to prove fault in our side is faulty logic.

Comment 6

[Johnny Stenback (:jst)]

Timeless, the majority of the new Java plugin code is shared between the IE version and the NPRuntime version, only a thin layer (IDispatch vs NPRuntime, plus bootstrapping code etc) differs. And Kenneth wrote that plugin, so yes, he knows :)

Comment 7

[Kenneth Russell]

I see no crash with the current 1.6.0_10 Java Plug-In code (which is a few weeks ahead of the version available at http://jdk6.dev.java.net/6uNea.html , though no Firefox-specific bugs have been fixed recently) and the latest FF 3 nightly on Windows XP. There are plenty of error messages printed to the Java Console because of the malformed applet tags, but no browser crash.

Comment 8

[Martijn Wargers (dead)]

Attachment: testcase

Ok, I just installed the "jre-6u10-beta-bin-b21-windows-i586-p-04_apr_2008.exe" Java version.
That one indeed seems to have fixed the crash with the url at least.

But I can still reproduce this crash with the attached testcase. This is what I get in the debugger:
>	gklayout.dll!nsObjectFrame::CallSetWindow()  Line 911 + 0x44 bytes	C++
 	gklayout.dll!nsObjectFrame::Instantiate(const char * aMimeType=0x0583dc20, nsIURI * aURI=0x0499a458)  Line 1690	C++
 	gklayout.dll!nsObjectLoadingContent::Instantiate(nsIObjectFrame * aFrame=0x05811424, const nsACString_internal & aMIMEType={...}, nsIURI * aURI=0x0499a458)  Line 1692 + 0x1a bytes	C++
 	gklayout.dll!nsAsyncInstantiateEvent::Run()  Line 148 + 0x22 bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f848)  Line 511	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x012b4020, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 170 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 181 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x003ff7a8, const nsXREAppData * aAppData=0x003ffe50)  Line 3170 + 0x25 bytes	C++
 	firefox.exe!NS_internal_main(int argc=1, char * * argv=0x003ff7a8)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=1, unsigned short * * argv=0x003fa068)  Line 87 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 403	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes	

So it seems like the same crash issue.

Comment 9

[Martijn Wargers (dead)]

This is now nr. 36 in the topcrasher list for Firefox 3, fwiw.

Comment 10

[Johnny Stenback (:jst)]

Attachment: Fix.

Comment 11

[Johnny Stenback (:jst)]

The fix I just attached is an extension to the guess at a fix in bug 354102. The above patch might very well also fix bug 354102.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 327144 [details] [diff] [review]
Fix.

Looking good

Comment 13

[Johnny Stenback (:jst)]

Fix checked in.

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 327144 [details] [diff] [review]
Fix.

Perfectly safe top-crash fix, we should get this in for 1.9.0.1

Comment 15

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

I tried to verify this bug with a current 1.9.1 nightly build, but there is something wrong with the Java Plugin detection. Minefield doesn't recognize Java 6 update 10 beta 25 (or any other installed Java version) but Gran Paradiso is able to. As far as I can see this started when 1.9.1 builds are build from mozilla-central. Is there any bug report about that? If not, I'll file a new bug.

Comment 16

[Johnny Stenback (:jst)]

Henrik, Java works now on Windows and *nix, assuming you have the right version. See bug 435334...

Comment 17

[Johnny Stenback (:jst)]

Sorry, bug 435334 hasn't completely landed yet, but once it has Java will work once again.

Comment 19

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

Verified with given testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071203 Minefield/3.1a1pre ID:2008071203

Comment 21

[Samuel Sidler (old account; do not CC)]

Is there any way we can get a test for this?

Comment 22

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

While trying to get reproduced this crash for Firefox 3.0.1 I crashed with another top frame "jpinscp.dll@0xd025".

bp-4723ef00-58a0-11dd-8db1-0013211cbf8a

Martijn, do you know if there is another bug about this specific crash? There are bug 358102 and bug 368818 open with a similar problem.

Comment 23

[Martijn Wargers (dead)]

I think I saw that crash too quite a few times, while testing this. I think it all went away when Johnny's patch was checked in.

Comment 24

[luna]

will the fix be included in the next firefox update?

Comment 25

[luna]

here firefox 3.0.1 doesn´t crash with the testcase above anymore...

the login page of http://www.netbanking.at crashes almost every time clicking on "netbanking Login - Button"

Comment 26

[luna]

sorry firefox crashes with testcase also... seems like it works if firefox was running some time before...

Comment 27

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

(In reply to comment #23)
> I think I saw that crash too quite a few times, while testing this. I think it
> all went away when Johnny's patch was checked in.

Indeed. With a current build I'm not able to reproduce this crash.

(In reply to comment #25)
> here firefox 3.0.1 doesn´t crash with the testcase above anymore...
> 
> the login page of http://www.netbanking.at crashes almost every time clicking
> on "netbanking Login - Button"

This patch wasn't checked into the Firefox 3.0.x branch yet. So it's not fixed for Firefox 3.0.1. We are still waiting for approval. When it is fixed it will be marked as fixed1.9.0.2 within the status whiteboard.

Comment 28

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

(In reply to comment #21)
> Is there any way we can get a test for this?

Martijn, can your testcase be used for the test suite or has it to be modified?

Comment 29

[Johnny Stenback (:jst)]

We unfortunately can't use testcases that depend on plugins in our test suites yet :(

Comment 30

[Samuel Sidler (old account; do not CC)]

Johnny, is there a bug on file for making that possible?

In the mean time, I think we need a Litmus testcase for this.

Comment 32

[Samuel Sidler (old account; do not CC)]

Comment on attachment 327144 [details] [diff] [review]
Fix.

I'm approving this for now knowing that we'll get a Litmus testcase added later.

Approved for 1.9.0.2. Please land in CVS. a=ss

Comment 33

[Johnny Stenback (:jst)]

Fix landed in CVS.