Community
Participate
Working Groups
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)
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.
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); } }
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
Mozilla support is removed in 4.8.
