Community
Participate
Working Groups
Build Identifier: 20100917-0705 Eclipse crashes whenever I try to add a reference to a method to a javadoc comment by using autocomplete feature. I am using Java(TM) SE Runtime Environment (build 1.6.0_24-b07) on x32 architecture. I do see different error reports from jvm: (1) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xaf535f14, pid=32208, tid=3074636656 # # JRE version: 6.0_24-b07 # Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode, sharing linux-x86 ) # Problematic frame: # C [libxul.so+0x1025f14] (2) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb0e5b8d9, pid=32067, tid=3076205424 # # JRE version: 6.0_24-b07 # Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode, sharing linux-x86 ) # Problematic frame: # C [UTF-16.so+0x8d9] gconv+0x3c9 I read about CDT Indexer because I experienced a lot of crashes today. Indexer is already turned off - just in case. Reproducible: Always Steps to Reproduce: 1. create a class with some methods 2. start writing a javadoc comment for a method 3. enter # and wait for autocomplete to appear 4. crash...
Does the crash happen immediately after content assist (first window) opens or shortly after when it tries to open the Javadoc hover on the right? See also bug 341095 and bug 340998.
Can you attach the full crash logs so that we can see the libraries that are loaded, etc.?
Created attachment 192402 [details] error_xulrunner.log
Created attachment 192403 [details] error_utf16.log
(In reply to comment #1) > Does the crash happen immediately after content assist (first window) opens or > shortly after when it tries to open the Javadoc hover on the right? I can see a glimpse of the content assist window. It is already populated with the methods available in this class. About half a second later the application crashes. > See also bug 341095 and bug 340998. Might be a dupe. I am using xulrunner 2.0 too.
Yes, I see you're on Eclipse 3.6.1, this should become fixed if you move up to 3.6.2. Closing report as duplicate. *** This bug has been marked as a duplicate of bug 319123 ***
(In reply to comment #6) > Yes, I see you're on Eclipse 3.6.1, this should become fixed if you move up to > 3.6.2. Closing report as duplicate. I just upgraded to 3.6.2 but still experience the same behavior. Eclipse still just exits (now without a sigsev) when I open the autocomplete on a javadoc reference. Still there is something new to report: I do get the sigsevs on xulrunner and utf-16 when editing java source. I can work about 2-3 minutes, afterwards eclipse crashes. I cannot say that it happens on a specific action I take. Eclipse version I'm on right now: Version: Helios Service Release 2 Build id: 20110301-1815
Can you attach a crash log that you get with eclipse 3.6.2?
Created attachment 193217 [details] hs_err_pid_UTF16.log
Created attachment 193218 [details] hs_err_pid_libxul.log
The new logs indicate that it's still attempting to use xulrunner-2.0, which is not supported. Are you doing anything to explicitly point at your xulrunner-2.0 install, like setting the org.eclipse.swt.browser.XULRunnerPath java system property, or the MOZILLA_FIVE_HOME environment variable?
*** Bug 341095 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > The new logs indicate that it's still attempting to use xulrunner-2.0, which is > not supported. I recently upgraded to firefox 4, which pulls in xulrunner-2.0 on my gentoo box. I see now that xulrunner 2.0 is not supported which explains the crashes. Bug 340998, comment #2 describes a workaround which is ok for me. Will xulrunner 2.0 be supported in eclipse 3.7?
(In reply to comment #11) > Are you doing anything to explicitly point at your > xulrunner-2.0 install, like setting the org.eclipse.swt.browser.XULRunnerPath > java system property, or the MOZILLA_FIVE_HOME environment variable? No. Did not set anything of these.
XULRunner 2.0 won't be supported in Eclipse 3.7, but the default Browser renderer used on Linux will change from Mozilla-based (XULRunner) to WebKitGTK. Anyone using a Linux distro that's modern enough to only have a XULRunner version >= 2.0 will also have WebKitGTK available. Question: I'd still like to figure out why it's attempting to use XULRunner-2.0 for you. Do any of the following files exist on your machine, and if so, what is their content? /etc/gre64.conf /etc/gre.d/gre64.conf /etc/gre.conf /etc/gre.d/gre.conf
(In reply to comment #15) > Question: I'd still like to figure out why it's attempting to use XULRunner-2.0 > for you. Do any of the following files exist on your machine, and if so, what > is their content? > > /etc/gre64.conf > /etc/gre.d/gre64.conf > /etc/gre.conf > /etc/gre.d/gre.conf None of these files exist on my system. However there is /etc/gre.d/2.0.system.conf with following content: [2.0] GRE_PATH=/usr/lib/xulrunner-2.0 xulrunner=true abi=x86-gcc3
This is bizarre, I don't think the Eclipse launcher would see that file. Could something else in the linux distro be pointing at the xulrunner? Would you mind trying the snippet below, to see what it writes to stdout? It just uses SWT; use Ctrl+Shift+O to resolve all required imports. public class ModifiedSnippet148 { public static void main(String[] args) { System.out.println( "org.eclipse.swt.browser.XULRunnerInitialized=" + System.getProperty("org.eclipse.swt.browser.XULRunnerInitialized")); int /*long*/ ptr = C.getenv (wcsToMbcs (null, XPCOM.MOZILLA_FIVE_HOME, true)); System.out.print("MOZILLA_FIVE_HOME="); if (ptr == 0) { System.out.println("null"); } else { int length = C.strlen (ptr); byte[] buffer = new byte[length]; C.memmove (buffer, ptr, length); System.out.println(new String(mbcsToWcs (null, buffer))); } Device.DEBUG = true; final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Browser browser = null; try { browser = new Browser(shell, SWT.MOZILLA); } catch (SWTError e) { } display.dispose(); } static char[] mbcsToWcs(String codePage, byte[] buffer) { return Converter.mbcsToWcs(codePage, buffer); } static byte[] wcsToMbcs(String codePage, String string, boolean terminate) { return Converter.wcsToMbcs(codePage, string, terminate); } }
(In reply to comment #17) > Could something else in the linux distro be pointing at the xulrunner? Would > you mind trying the snippet below, to see what it writes to stdout? It just > uses SWT; use Ctrl+Shift+O to resolve all required imports. This is the output produced by the snippet: org.eclipse.swt.browser.XULRunnerInitialized=null MOZILLA_FIVE_HOME=/usr/lib/xulrunner-devel-2.0 HTH
Another question, based on bug 343930. Do any of the files below exist on your machine, and if so, are any of them actually links to /usr/lib/xulrunner-2.0 or /usr/lib/xulrunner-devel-2.0 ? /usr/lib/xulrunner/ /usr/lib64/xulrunner/ /usr/local/xulrunner/ /opt/xulrunner/
(In reply to comment #19) > Do any of the files below exist on your machine > > /usr/lib/xulrunner/ > /usr/lib64/xulrunner/ > /usr/local/xulrunner/ > /opt/xulrunner/ None of these folders exits. On my machine there exist /usr/lib/xulrunner-2.0 and /usr/lib/xulrunner-devel-2.0 where the latter has symlinks to xulrunner-2.0
I'm quite sure this is a case of bug 343454, which is fixed as of today's I-build ( http://download.eclipse.org/eclipse/downloads/drops/I20110510-0800/index.php , currently still replicating). When you have a chance please give it a try, either with this build or with a later one, and if you still see the problem then this report can be reopened. *** This bug has been marked as a duplicate of bug 343454 ***
