Community
Participate
Working Groups
SWTError (XPCOM error -2147467259) when using the SWT 3.3 Broswer widget on Linux with Mozilla 1.7.8 When using the eclipse-SDK-I20070123-1715 driver, creaating a SWT Browser widget causes the following exception: org.eclipse.swt.SWTError: XPCOM error -2147467259 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1308) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:262) at org.eclipse.swt.browser.Browser.<init>(Browser.java:99) JRE: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20061002a (SR3) ) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20061001 (JIT enabled) J9VM - 20060915_08260_lHdSMR JIT - 20060908_1811_r8 GC - 20060906_AA) JCL - 20061002 OS: Linux paules 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Mozilla: Mozilla 1.7.8 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050511 According to the SWT FAQ, this configuration is supported.
Must fix for 3.3.
I think you have a 32-bit XULRunner install either on your 64-bit machine or on a network that your machine sees. Am I correct?
(In reply to comment #2) > I think you have a 32-bit XULRunner install either on your 64-bit machine or on > a network that your machine sees. Am I correct? Most likely since Mozilla 1.7.8 from http://www.mozilla.org/releases is installed on this 64 bit machine and Mozilla only offers the one download (assuming it is 32 bit).
Trying to use a 32-bit GRE would fail like this. However given where the crash occurred it seems like it's finding a 1.8-based mozilla. Can you try the following: - if you are unable to start eclipse then set environment variable MOZILLA_FIVE_HOME to /dev/null (or if you can start eclipse then ignore this step) - retrieve swt from cvs into your workspace and compile it for gtk as outlined in http://www.eclipse.org/swt/cvs.php - run the following snippet against the swt in your workspace: public static void main(String[] args) { Display.DEBUG = true; final Display display = new Display(); Shell shell = new Shell(display); shell.setBounds(10,10,200,200); Browser browser = new Browser(shell, SWT.NONE); browser.setBounds(10,10,150,150); browser.setUrl("google.ca"); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } - a line should be spewed to your Console view, what is it?
A couple of details to add to comment 4: - make sure to retrieve the org.eclipse.swt.gtk.linux.x86_64 fragment from cvs, not org.eclipse.swt.gtk.linux.x86 - after renaming .classpath_gtk to .classpath you may also need to change its <attributes> line from <attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="org.eclipse.swt.gtk.linux.x86"/> to <attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="org.eclipse.swt.gtk.linux.x86_64"/>
(In reply to comment #4) Thanks Grant for your help. After following your instructions, I get the following exception when extracting/using the org.eclipse.swt.gtk.linux.x86_64 plug-in: Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.swt.widgets.Display (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:123) at org.eclipse.hyades.test.Test.main(Test.java:11) Caused by: java.lang.Throwable: java.lang.UnsatisfiedLinkError: no swt-gtk-3327 or swt-gtk in swt.library.path, java.libary.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:219) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) at java.lang.J9VMInternals.initialize(J9VMInternals.java:144) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:128) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:127) at org.eclipse.swt.graphics.Device.<clinit>(Device.java:101) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) at org.eclipse.hyades.test.Test.main(Test.java:10) Interestingly, I beleive I get the desired output with the org.eclipse.swt.gtk.linux.x86 plug-in: XULRunner path: /usr/lib64/xulrunner-1.8.0.1/libxpcom.so Exception in thread "main" org.eclipse.swt.SWTError: XPCOM error -2147467259 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1212) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:236) at org.eclipse.swt.browser.Browser.<init>(Browser.java:109) at org.eclipse.hyades.test.Test.main(Test.java:14)
(In reply to comment #4) > Trying to use a 32-bit GRE would fail like this. There is no IBM 1.5 64-bit JRE (only 1.3.1 and 1.4.2).
(In reply to comment #4) > However given where the crash > occurred it seems like it's finding a 1.8-based mozilla. There is Firefox 1.5.0.4 installed on the machine: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.4) Gecko/20060527 SUSE/1.5.0.4-1.9 Firefox/1.5.0.4
Sorry, mistakenly reassigned to default component owner.
I see, so you're running: - 32-bit eclipse - with a 32-bit VM - on a 64-bit linux install - failing because the xulrunner dynamic lookup is finding a 64-bit XULRunner, which does not agree with the 32-ness of your eclipse + VM This is the exact reverse (but basically the same) of what I'd assumed and have seen happen here: - 64-bit eclipse - with a 64-bit VM - on a 64-bit linux install - failing because the xulrunner dynamic lookup is finding a 32-bit XULRunner, which does not agree with the 64-ness of the eclipse + VM I've posted a question about this scenario on the mozilla embedding list, and the response from Benjamin S. is that the XULRunner dynamic lookup does not handle detection of a XULRunner with the wrong arch. The only way I can think of handling this is to attempt to fall back to using mozilla if the XULRunner glue startup fails. As a side note, there is an IBM 1.5 64-bit JRE available internally on JIM.
(In reply to comment #10) Interestingly, the same OS/JRE/Mozilla configuration worked with Eclipse 3.2.1 and 3.2.2.
re: comment 11 When you run 32-bit eclipse 3.2.1 or 3.2.2 on your 64-bit machine, does the Welcome page appear white or greenish?
(In reply to comment #10) As expected, the Browser widget works with the following configuration: 64 bit (EM64T) IBM JRE 1.5 SR4 64 bit Linux Eclipse That said, I would be interested to know what changed on the SWT side between 3.2.2 and 3.3 for this configuration. Our users need to be able to run in a 32-bit mode on a 64-bit machine.
(In reply to comment #12) > re: comment 11 > > When you run 32-bit eclipse 3.2.1 or 3.2.2 on your 64-bit machine, does the > Welcome page appear white or greenish? > Greenish in 3.2.2.
fixed > 0223 When a XULRunner is detected, a glue test is attempted on it before loading swt's xulrunner library. If the test fails then the behaviour falls back to the classic mozilla detection and swt mozilla library. > interested to know what changed on the SWT side between 3.2.2 and 3.3 As part of the mozilla everywhere work the mozilla implementation of the browser became cross-platform. This included a change to detect a XULRunner install to use by statically linking XULRunner code that sniffs around at runtime, rather than the previous practice of requiring the user to set MOZILLA_FIVE_HOME and LD_LIBRARY_PATH. The new approach is considered to be the right one, and ensures that the correct xulrunner libraries are loaded. Unfortunately when detecting a XULRunner to use there's no way to specify an arch, nor is there a way to say "I don't like the first one you gave me so please find me another one", hence the test-and-fallback strategy.
Verified in the N20070301-0010 Eclipse 3.3 build. Thanks Grant for your help with this defect.
Closing.
