SWT.Browser.execute: assert fail (causing exit) jsapi.cpp:5060 when using --enable-debug



Core Graveyard
Java to XPCOM Bridge
8 years ago
4 years ago


(Reporter: Bart OL-NL, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko.

Inability to use a debug build of XULRunner (--enable-debug in mozconfig) for SWT.Browser component.

Key facts: 
- unexpected exit by assert fail on assert when browser disposed
- unexpected exit by assert fail when using browser.execute() or BrowserFunction (uses .execute internally)

Reproduced on WinXP sp3 and Mac OSX 10.5.8; therefore suspected to be crossplatform issue.

non --enable-debug builds seem to work with SWT.Browser on both XP and OSX, so unclear if SWT.Browser should be updated to use  JS_BeginRequest / JS_SetContextThread, or that the assert is 'off' in this situation?

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("")
4.2 Use BrowserFunction() (also invokes JS execute code)

Actual Results:  
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

Expected Results:  
Proper functioning of SWT.Browser

- Without --enable-debug in mozconfig:
browser works -seemlingly- OK

- With --enable-debug in mozconfig:
issue as outlined occurs. When *not* using browser.Execute, pages can be loaded (albeit some assert message windows pop up, but simmilar exit when application closes (disposal of browser).
Additionally, during browser create, many XPCom warnings, same warning from many NS.....cpp files: 
WARNING: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0', file c:/192src/xpcom/base/nsTraceRefcntImpl.cpp, line 979

Comment 1

8 years ago
Created attachment 460845 [details]
Full eclipse console output, showing warnings and assert failure

Comment 2

8 years ago
There is currently no maintainer for JavaXPCOM and it has been disabled for future releases, so nobody is likely to look at this bug unless you do or a maintainer steps up.
Assignee: nobody → jhpedemonte
Component: XULRunner → Java to XPCOM Bridge
Product: Toolkit → Core
QA Contact: xulrunner → xpcom-bridge

Comment 3

8 years ago
My apologies but it is not completely clear to me what this means exactly;.

My questions are:

1. Disabled for future due to lack of maintainer; does this mean java XPCom is depricated, and if so, for what reason (lack of manpower, strategic decision, maintainer abandoning team, ...)? 

2. There seems to be a fairly large user base for SWT.Browser using mozilla, if it has no more future, (where) is this decision documented / communicated?

4. Does this mean that SWT.Browser will no longer be able to use future versions of XULRunner/Mozilla at all?

5. Does the assert indicate that (due to possible threading issues) using 1.9.x(?)  with SWT.Browser is already to be considered 'very dangerous'; due to lacking in mentioned JS_BeginRequest / JS_SetContextThread constructs?

This information is of course of great importance of any project planning on using mozilla as engine in any java application.

Comment 4

8 years ago
1. JavaXPCOM was implemented by IBM for Eclipse. Mozilla is happy to host the code, but we have no particular interest in actively maintaining it. IBM has stopped maintaining the code, and it broke, so it has been removed in Firefox 4/Mozilla 2.

2. This was discussed a while back on the http://dev.eclipse.org/mhonarc/lists/atf-dev/msg00603.html and Jacek has not actually split the embedding since then. The final decision to disable and remove JavaXPCOM was made last week when it broke and has not been fixed.

4. No, but it does mean that someone will need to actively develop and maintain the bridge code, and it will no longer be included in XULRunner itself.

5. Well, it does indicate a bug. I'm not sure how serious this bug is, since almost all of our JS code runs on the main thread in any case.

Comment 5

8 years ago
Thank you for the information; much appreciated.

Grant Gayed at SWT team has been kind enough to clarify the situation a bit more to me (I mistakenly expected SWT.browser to be dependant on javaXPCom, which isnt the case, the browser control uses a swt private JNI dll that links to native xpcomglue.lib).

His reply can be read here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321145

So swt.browser control with SWT.MOZILLA seems to have a future if I understand correctly (at least for applications not doing 'extra' things outside the Browser class interface using javaxpcom).

I'm keeping an eye on the bug (likely it is on swt side), and report here if I have news.

Comment 6

8 years ago
The problem is with SWT, I made a private SWT build with a adjusted native DLL on windows where I added JS_Begin/End request calls and then the problem no longer occurs; see https://bugs.eclipse.org/bugs/show_bug.cgi?id=321145

I think that for mozilla this item can be closed.


4 years ago
Assignee: jhpedemonte → nobody


4 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.