+++ This bug was initially created as a clone of Bug #681903 +++

Description of problem:
Eclipse crashes with Sun JDK when using CDT

When eclipse is loaded with a CDT project, it crashes the JVM when rebuilding the index. It seems this issue is caused due to Compressed Ordinary Object Pointers (Compressed Oops) being turned on in the newer Java HotSpot versions (update 23 onwards). With the update of Sun JDK packages in el6 to update 24, we are now running into this problem. FC14 had similar issues and it seems an updated eclipse package fixed the issue.

https://bugzilla.redhat.com/show_bug.cgi?id=647737

Can we get eclipse patched in el6 as well?

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Make sure java-1.6.0-sun-1.6.0.24-1jpp.1.el6.x86_64 package is installed and is being used:

% rpm -qa | grep java-1.6.0-sun-1.6.0.24
java-1.6.0-sun-1.6.0.24-1jpp.1.el6.x86_64

% update-alternatives --display java | grep -i link
 link currently points to /usr/lib/jvm/jre-1.6.0-sun.x86_64/bin/java

% java -version 
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

2. Now run Eclipse (with CDT installed)
3. Create a C++ project
4. Add a main.cpp
5. add one line "#include <iostream>"
6. Save the file
7. If eclipse didn't crash right after saving, right click on the project and select Index->Rebuild Index



  
Actual results:

Eclipse crashes here with the following:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f578c31889b, pid=10684, tid=140012374947584
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# j  org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPSemantics.declaredBefore(Ljava/lang/Object;Lorg/eclipse/cdt/core/dom/ast/IASTNode;Z)Z+15
#
# An error report file with more information is saved as:
# /home/fahome/nkumar/hs_err_pid10684.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Expected results:
Normal operation

Additional info:

This only happens with the Sun JDK.

--- Additional comment from alanm on 2011-03-03 09:52:15 EST ---

Created attachment 482100 [details]
hs_err_pid10684.log

--- Additional comment from alanm on 2011-03-03 09:53:41 EST ---

Created attachment 482101 [details]
sosreport-nkumar.00427426-20110225112752-8d61.tar.xz

--- Additional comment from overholt on 2011-03-03 11:09:15 EST ---

This looks like bug #647737.  Can you try adding -XX:-UseCompressedOops to /etc/eclipse.ini?

--- Additional comment from ptisnovs on 2011-03-03 11:19:33 EST ---

Created attachment 482115 [details]
Reproduced for compressed oops issue

--- Additional comment from ptisnovs on 2011-03-03 11:22:15 EST ---

There's a reproduced for compressed oops issue stored in the attachment 482115 [details] (see comment #4). You can compile & run it to check if your JDK version has already compressed oops fix.

--- Additional comment from overholt on 2011-03-03 12:00:44 EST ---

Do I just compile and run that test case?  I tried javac Test7002666.java; java Test7002666 with:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)

and got no errors.

--- Additional comment from ptisnovs on 2011-03-10 05:10:16 EST ---

If the test does not fail it means you are using fixed IcedTea version.

--- Additional comment from overholt on 2011-03-11 15:27:26 EST ---

(In reply to comment #7)
> If the test does not fail it means you are using fixed IcedTea version.

Does the version in comment #6 indicate that I am using the Sun JDK or the IcedTea version?  I thought it indicated Sun but I may be wrong.

--- Additional comment from overholt on 2011-05-16 13:00:11 EDT ---

I'm told this is fixed in newer versions of the Sun JDK so if we can get one of those into RHEL we'll be good to go and won't need to patch Eclipse to work around this JVM issue.

Re-assigning to the proper component.