Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321145

Summary: VM exit with SWT.Mozilla with debug version of XULRunner; indicating possible threading issue
Product: [Eclipse Project] Platform Reporter: Bart OL-NL <bartnll33>
Component: SWTAssignee: Grant Gayed <grant_gayed>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3    
Version: 4.0   
Target Milestone: ---   
Hardware: All   
OS: Windows XP   
Whiteboard:

Description Bart OL-NL CLA 2010-07-28 11:57:36 EDT 
Build Identifier: Build id: 20100218-1602

Seen on WinXP SP3 and Mac OSX, 

When using XULRunner build with --enable-debug, using browser.execute (and thus also using any custom BrowserFunction) causes assertion failed (in turn causing hard exit).

Unexpected termination of javaw, caused by assertion failed
Assertion failure: (cx)->requestDepth || (cx)->thread ==
(cx)->runtime->gcThread, at c:/192src/js/src/jsapi.cpp:5060

This may be indicating issues of SWT.Browser with mozilla 1.9.2 (1.9.x?); maybe missing JS_BeginRequest / JS_SetContextThread, possibly required due to JS engine being threadsafe by default now.

Release xulrunner seems to work, but threading issues might be hiding out here, and more importantly; is this a indication of limited horizon of SWT.Browser/Mozilla compatibility? (see conversation at end of bug report on mozilla.org, mentioning javaXPCom bridge no longer being maintained):

https://bugzilla.mozilla.org/show_bug.cgi?id=582567


Reproducible: Always

Steps to Reproduce:
1. Build xulrunner from source 1.9.2, using --enable-debug
2. SWT app with SWT.Browser; snippet to do this:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet128.java?view=co
3. Make sure to use SWT.Mozilla and set system property
"org.eclipse.swt.browser.XULRunnerPath" to the XULRunner build
4.1 Use browser.Execute("")
or
4.2 Use BrowserFunction() (also invokes JS execute code)
Comment 1 Grant Gayed CLA 2010-07-28 12:09:18 EDT 
Thanks for reporting this, I'll take a look.

SWT's ability to embed XULRunner is not dependent on JavaXPCOM, we make all calls to it via C++ vtbl invocations.  That being said, Browsers created with style SWT.NONE on linux will first attempt to use WebKitGTK (if it's installed on the machine) instead of XULRunner as of eclipse/swt 3.7.  It will still be possible to force the Browser to use XULRunner if it is created with style SWT.MOZILLA.  However the connotation of SWT.NONE-style Browsers is that the native renderer being used is not of major consequence to the client.

SWT clients that use its exposed JavaXPCOM functionality seemingly will be restricted to using XULRunner versions < 2.0.  I don't think this is a problem since such clients should really be shipping a XULRunner with their app anyways, to ensure that the XPCOM interfaces they invoke are kept consistent.  If just means that they won't be able to take advantage of features/fixes released in XULRunner >= 2.0.
Comment 2 Bart OL-NL CLA 2010-08-03 03:56:32 EDT 
Thank you for the clarification on javaXPCom (happy with that!).

I've build the DLL's, and adjusted the call, adding begin/end request effectively prevents the assert and results in proper execution of script; maybe this is of some use.

Kind regards,
Bart

xpcom_custom.cpp (@line 57):

#define JS_BeginRequest_LIB "js3250.dll"
#define JS_EndRequest_LIB "js3250.dll"

LOAD_FUNCTION(fp, JS_EvaluateUCScriptForPrincipals)
if (fp) {
	{
		LOAD_FUNCTION(begin, JS_BeginRequest);
			(( void  (*)(jintLong))begin)(arg0);
	}
	rc = (jint)((jint (*)(jintLong, jintLong, jintLong, jchar *, jint, jbyte *, jint, jintLong *))fp)(arg0, arg1, arg2, lparg3, arg4, lparg5, arg6, lparg7);
	{
		LOAD_FUNCTION(end, JS_EndRequest);
		(( void  (*)(jintLong))end)(arg0);
	}
}
Comment 3 Bart OL-NL CLA 2012-06-04 08:01:02 EDT 
Additional information,

Also on 3.8 + xulrunner10, note that for that case JS_begin/endRequest no longer comes from js3250.dll but from mozjs.dll

Assert seems legitimate, https://developer.mozilla.org/en/JS_THREADSAFE
Comment 4 Alexander Kurtakov CLA 2017-07-04 13:39:41 EDT 
Mozilla support is removed in 4.8.