Bugzilla – Full Text Bug Listing
| Summary: | [Browser] Browser fails when 32-bit XULRunner detected on 64-bit OS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | _ <b3788686> | ||||||||
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | eclipse, gheorghe, grant_gayed, remy.suen, steffen.pingel | ||||||||
| Version: | 3.6 | Flags: | carolynmacleod4:
review+
gheorghe: review+ |
||||||||
| Target Milestone: | 3.7 RC2 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
_
also, fyi locate swt | grep \.so | grep lib | grep usr /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64.source_3.4.0.v3448f.jar /usr/lib64/swt/libswt-atk-gtk-3347.so /usr/lib64/swt/libswt-awt-gtk-3347.so /usr/lib64/swt/libswt-cairo-gtk-3347.so /usr/lib64/swt/libswt-glx-gtk-3347.so /usr/lib64/swt/libswt-gnome-gtk-3347.so /usr/lib64/swt/libswt-gtk-3347.so /usr/lib64/swt/libswt-mozilla-gtk-3347.so /usr/lib64/swt/libswt-pi-gtk-3347.so /usr/local/eclipse/libcairo-swt.so This looks like a problem with the local xulrunner installation. Please see http://www.eclipse.org/swt/faq.php#specifyxulrunner . What is the actual error that is displayed in the editor of the task editor (not when you click the link)? (In reply to comment #2) > This looks like a problem with the local xulrunner installation. Please see > http://www.eclipse.org/swt/faq.php#specifyxulrunner . I have. It states there: "Typically a Mozilla-based Browser uses XULRunner's lookup mechanism to find a registered XULRunner at runtime, in which case a XULRunner location does not need to be specified" checking, xulrunner --gre-version 1.9.2.8 xulrunner --find-gre 1.9.2.8 /usr/lib64/xulrunner-1.9.2.8/libxpcom.so ls -al /usr/lib64/xulrunner-1.9.2.8/libxpcom.so -rwxr-xr-x 1 root root 18904 2010-08-04 01:31 /usr/lib64/xulrunner-1.9.2.8/libxpcom.so xulrunner finds it -- so should Eclipse, right? > What is the actual error > that is displayed in the editor of the task editor (not when you click the > link)? "Submit failed: An unknown repository error has occurred: not allowed" I would recommend filing the xulrunner bug against platform. There is nothing we can do to address this in Mylyn except to handle the error better (tracked on bug 316234). Frank, do you know what the "not allowed" error on submission indicates? just checking in @ ~1wk. triage? Just to confirm, pressing the Submit button is the first time that a Browser widget is created, right? (ie.- you say you're able to see bugzilla reports, but they're being shown somewhere other than in a Browser widget). It's possible that swt's library is failing to load if it's detecting your 32-bit xulrunner. Can you try pointing the Browser explicitly at one of your 64-bit xulrunners by specifying a -D launch property as described in http://www.eclipse.org/swt/faq.php#specifyxulrunner (note that the instructions are slightly outdated, you should add this -D... switch in your eclipse.ini file before launching eclipse). (In reply to comment #6) > Just to confirm, pressing the Submit button is the first time that a Browser > widget is created, right? (ie.- you say you're able to see bugzilla reports, > but they're being shown somewhere other than in a Browser widget). here's what I see when I 'view' the bug, http://img163.imageshack.us/img163/4899/eclipsez.png when I make a change, and click on Submit, i get: http://img842.imageshack.us/img842/8130/eclipse2.png that's it. > It's possible that swt's library is failing to load if it's detecting your > 32-bit xulrunner. Can you try pointing the Browser explicitly at one of your > 64-bit xulrunners by specifying a -D launch property as described in > http://www.eclipse.org/swt/faq.php#specifyxulrunner (note that the instructions > are slightly outdated, you should add this -D... switch in your eclipse.ini > file before launching eclipse). i changed/added @ /usr/local/eclipse/eclipse.ini, -startup ++ -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8 plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library ... with no apparent effect. error occurs as before. i also tried (docs are unclear -- folder, or file, path?) -D.../usr/lib64/xulrunner-1.9.2.8/libxpcom.so again, no dice. Sorry, the -D switch to add to eclipse.ini would be... -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8/ ...and it should be added at the end of the eclipse.ini file to ensure that it follows the -vmargs switch. (In reply to comment #8) > Sorry, the -D switch to add to eclipse.ini would be... > > -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8/ > > ...and it should be added at the end of the eclipse.ini file to ensure that it > follows the -vmargs switch. and that seems to do the trick. no error, and "successful submission" thx! Ok, that's good to hear. XULRunner's detection functionality does not provide a way to specify whether a 32- or 64-bit gecko is to be detected, so if it gets the wrong one then the Browser's only recourse is to guess at another location. Since your error logs indicate that the swt-mozilla library is failing to load (not the swt-xulrunner library) I suspect that this is what's happening. As a data point to see if cases like this may be better handled, can you run the snippet at http://www.eclipse.org/swt/faq.php#printmozillapath and paste its output here? (In reply to comment #10) > As a data point to see if cases like this may be better handled, can you run > the snippet at http://www.eclipse.org/swt/faq.php#printmozillapath and paste > its output here? Sure. "The SWT snippet below can be used to print the location of the Mozilla browser that was found." how? From inside of Eclipse? Standalone? I've Eclipsed configured for RSE, PHP & Mylyn use ... something else needs to be installed? Created attachment 177451 [details]
compiled DisplayMozillaVersion
I'm not sure if your eclipse contains the Java IDE, so the following should be the easiest way to do this:
- copy the attached .class file into your eclipse root directory
- at the command line cd to your eclipse root directory, then: (ensuring that the swt jar name below matches what you have)
% java -cp .:plugins/org.eclipse.swt.gtk.linux.x86_64_3.6.0.v3650b.jar DisplayMozillaVersion
(In reply to comment #12) > I'm not sure if your eclipse contains the Java IDE, aha. no. it doesn't > so the following should be the easiest way to do this: thanks here's the output, as requested: java -cp .:plugins/org.eclipse.swt.gtk.linux.x86_64_3.6.0.v3650b.jar DisplayMozillaVersion >>>Snippet creating SWT.MOZILLA-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9.1.11 >>>This failed with the following error: org.eclipse.swt.SWTError: No more handles [Failed to use detected XULRunner: /usr/lib64/firefox] at org.eclipse.swt.SWT.error(SWT.java:4109) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:633) at org.eclipse.swt.browser.Browser.<init>(Browser.java:119) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13) Snippet creating SWT.NONE-style Browser cannot use detected XULRunner: /usr/lib/xulrunner-1.9.1.11 Mozilla path: /usr/lib64/firefox >>>succeeded Exception in thread "main" org.eclipse.swt.SWTError: XPCOM error -2147467262 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2347) at org.eclipse.swt.browser.Mozilla.unhookDOMListeners(Mozilla.java:2777) at org.eclipse.swt.browser.Mozilla.onDispose(Mozilla.java:2370) at org.eclipse.swt.browser.Mozilla$5.handleEvent(Mozilla.java:872) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263) at org.eclipse.swt.widgets.Widget.release(Widget.java:1080) at org.eclipse.swt.widgets.Control.release(Control.java:3302) at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293) at org.eclipse.swt.widgets.Canvas.releaseChildren(Canvas.java:208) at org.eclipse.swt.widgets.Decorations.releaseChildren(Decorations.java:469) at org.eclipse.swt.widgets.Shell.releaseChildren(Shell.java:2303) at org.eclipse.swt.widgets.Widget.release(Widget.java:1083) at org.eclipse.swt.widgets.Control.release(Control.java:3302) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:462) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:2239) at org.eclipse.swt.widgets.Display.release(Display.java:3221) at org.eclipse.swt.graphics.Device.dispose(Device.java:237) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:27) as suspected, seems to be confusion bet /usr/lib & /usr/lib64 ... Updating report title to reflect the underlying cause.
I'm a bit surprised that the Browser isn't handling this better, because when it fails to use a detected xulrunner it should fall back to trying the one found by the eclipse launcher. I'm wondering if the eclipse launcher is failing to provide an a good alternative xulrunner install to try. Questions:
1. Linux env. var. MOZILLA_FIVE_HOME is NOT set to anything before launching eclipse, right?
2. Does your linux install have any of the following files, and if so, what's in them?
/etc/gre64.conf
/etc/gre.d/gre64.conf
/etc/gre.conf
/etc/gre.d/gre.conf
(In reply to comment #14) > 1. Linux env. var. MOZILLA_FIVE_HOME is NOT set to anything before launching > eclipse, right? atm, that's correct > 2. Does your linux install have any of the following files, and if so, what's > in them? > /etc/gre64.conf > /etc/gre.d/gre64.conf > /etc/gre.conf > /etc/gre.d/gre.conf nope, ls -1 \ /etc/gre64.conf \ /etc/gre.d/gre64.conf \ /etc/gre.conf \ /etc/gre.d/gre.conf /bin/ls: cannot access /etc/gre64.conf: No such file or directory /bin/ls: cannot access /etc/gre.d/gre64.conf: No such file or directory /bin/ls: cannot access /etc/gre.conf: No such file or directory /bin/ls: cannot access /etc/gre.d/gre.conf: No such file or directory Created attachment 195396 [details]
patch that attempts to consider Mozilla ABI
On further investigation, XULRunner did actually start including ABI info in its registration a couple of releases ago, so it is possible for the Browser to give it hint regarding the desired architecture. The attached patch attempts to detect a XULRunner with this additional info provided.
The .classpath_gtk change is not meant to be part of the patch. Created attachment 195973 [details]
revised patch
Revised patch. This is the best that can be done to help the XULRunner detection magic find us a XULRunner that matches SWT's arch.
fixed > 20110518 |
