Created attachment 456422 [details] The error log saved after the crash Description of problem: The eclipse crashes whenever I try to index a C++ project. I've tried the same Eclipse version in Fedora 13 and it works fine, so it seems to be a non-eclipse problem. Apparently it is related to OpenJDK. Version-Release number of selected component (if applicable): java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run Eclipse (with CDT installed) (you can use either F14's eclipse or an eclipse cdt downloaded from eclipse.org. the bug happens in both). 2. Create a C++ project 3. Add a main.cpp 4. add one line "#include <iostream>" 5. Save the file 6. If eclipse didn't crash right after saving, right click on the project and select Indexer->Rebuild Index Actual results: Eclipse crashes Expected results: It should index the project successfully
Surely this should be filed against Eclipse?
As I said, I have an Eclipse Helios downloaded from eclipse.org. It works fine in Fedora 13, but fails in Fedora 14. The same thing happens with Fedora 14's own Eclipse Helios. So, I assumed that there is something wrong with F14's java. BTW, maybe this is an eclipse bug ?!! But this makes CDT completely useless, and I wonder if such a thing have been released by eclipse. Anyway, while this bug is present I should revert back to F13 or replace F14's openjdk with Sun's jdk. It should work there IMHO.
I've installed Sun JDK 1.6, and now eclipse works fine. So, there is something wrong in OpenJDK. This is a sever regression for Fedora 14 :(
Actually you didn't mention the Eclipse version in the original report (I assume that's what 'Helios' is). Have you tried using the F13 OpenJDK on F14? What is the -version output of the 'Sun JDK' that you say this doesn't occur in? (I assume that this is either an old version or you mean Oracle's proprietary JDK). The crash log shows that it occurs in Eclipse code so I still think this would be better diagnosed by someone familiar with Eclipse, especially if it occurs with the Fedora Eclipse packages as you state. There is a new version of HotSpot used in the F14 OpenJDK packages, but as far as I'm aware, Oracle are also packaging this with the new versions of their proprietary JDK.
Yes, this is Eclipse Helios: eclipse-platform-3.6.1-2.fc14.x86_64 eclipse-cdt-7.0.1-2.fc14.x86_64 No, I've not tried running F13 OpenJDK in F14. Is there anyway to do it rather than downgrading F14's OpenJDK? Yes, I meant Oracle JDK: [hedayat@localhost]~% java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) Yes, the problem occurs in Fedora Eclipse as well as Stock Eclipse from eclipse.org.
Ok, so your Oracle JDK is using HotSpot 17. OpenJDK's is newer; HotSpot 19. Can you replicate the problem with 6u23? http://download.java.net/jdk6/6u23/promoted/b03/binaries/ If so, the problem would seem to be in the upgrade from HotSpot 17 to 19. We can easily spin new RPMs using HotSpot 17 if this is the case, though it will cause a performance degradation and I'd prefer not to have to do this long-term. The F13 rpms are available at http://koji.fedoraproject.org/koji/buildinfo?buildID=200313 These use IcedTea6 1.8.2 and HotSpot 14 rather than IcedTea 1.9.1 and HotSpot 19. If we know that the F13 rpms work on your same F14 Eclipse environment, we know it's something to do with the OpenJDK upgrade.
Hello. I tried to reproduce this on F13, and I was able to. I couldn't reproduce it with Galileo and CDT 6.0, regardless of the java used. I had to use Helios and CDT version 7.0.1. I ran it with oracle's 6u21, 22, and 23. It crashed on u23 only. I also used icedtea6-1.8.2, and an HS17 build of icedtea6-1.9.1. It didn't crash with these two. Then I tried the latest icedtea6 with HS19 and also a build of one of the openjdk7 trees (with HS>19). Both of these crashed. I'm trying to isolate a hotspot changeset that causes problems (if any, but it certainly seems like hotspot is the problem).
(In reply to comment #6) > Ok, so your Oracle JDK is using HotSpot 17. OpenJDK's is newer; HotSpot 19. > > Can you replicate the problem with 6u23? Yes, I do too.
So HotSpot 19 is the issue. Denis, to find where the problem is introduced, you can perform a bisection using http://hg.openjdk.java.net/jdk7/hotspot/hotspot/tags. Take a look at hg bisect --help
Note that the default (hotspot.map) IcedTea6 hsx19 comes from master: http://hg.openjdk.java.net/hsx/hsx19/master/ Which is hs19-b06 But there have been fixes done that are only on baseline: http://hg.openjdk.java.net/hsx/hsx19/baseline/ Which is hs19-b09 You might want to investigate if this issue is fixed by one of the changes between b06 and b09 already.
I was just about to suggest the same thing :-) Denis, I'll update hs19 in HEAD and then you can test to see if the problem is resolved.
*** Bug 649234 has been marked as a duplicate of this bug. ***
While we try to figure out how to fix hotspot, could people who are seeing this problem try the following workaround to see if this is the only issue with eclipse? Add the following line at the end of your /etc/eclipse.ini file: -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPSemantics,declaredBefore That will instruct hotspot to not JIT that method. Which will make indexing slower, but might prevent the crash from happening.
Created attachment 458035 [details] error log from OpenJDK (In reply to comment #13) > While we try to figure out how to fix hotspot, could people who are seeing this > problem try the following workaround to see if this is the only issue with > eclipse? > > Add the following line at the end of your /etc/eclipse.ini file: > -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPSemantics,declaredBefore > > That will instruct hotspot to not JIT that method. Which will make indexing > slower, but might prevent the crash from happening. I did so and I was awarded with: jakoubek:~ $ CompilerOracle: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith CompilerOracle: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init> CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate CompilerOracle: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding CompilerOracle: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile CompilerOracle: exclude org/python/pydev/ui/filetypes/FileTypesPreferencesPage.getDottedValidSourceFiles CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPSemantics.declaredBefore # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fe421e93989, pid=9673, tid=140617772861184 # # JRE version: 6.0_20-b20 # Java VM: OpenJDK 64-Bit Server VM (19.0-b06 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.9.1 # Distribution: Custom build (Wed Oct 13 22:53:58 UTC 2010) # Problematic frame: # V [libjvm.so+0x622989] # # An error report file with more information is saved as: # /home/matej/hs_err_pid9673.log [thread 140617773913856 also had an error] # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # jakoubek:~ $
Created attachment 458037 [details] Backtrace from ABRT
(In reply to comment #14) > I did so and I was awarded with: > jakoubek:~ $ CompilerOracle: exclude > org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith > CompilerOracle: exclude > org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init> > CompilerOracle: exclude > org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate > CompilerOracle: exclude > org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding > CompilerOracle: exclude > org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile > CompilerOracle: exclude > org/python/pydev/ui/filetypes/FileTypesPreferencesPage.getDottedValidSourceFiles > CompilerOracle: exclude > org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPSemantics.declaredBefore > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fe421e93989, pid=9673, tid=140617772861184 > # > # JRE version: 6.0_20-b20 > # Java VM: OpenJDK 64-Bit Server VM (19.0-b06 mixed mode linux-amd64 compressed > oops) > # Derivative: IcedTea6 1.9.1 > # Distribution: Custom build (Wed Oct 13 22:53:58 UTC 2010) > # Problematic frame: > # V [libjvm.so+0x622989] > # > # An error report file with more information is saved as: > # /home/matej/hs_err_pid9673.log Thanks for trying. Could you inspect and/or attach the hs_err_pid9673.log to see where/what it is crashing now?
(In reply to comment #16) > Thanks for trying. Could you inspect and/or attach the hs_err_pid9673.log to > see where/what it is crashing now? O, it was already there in comment #14. Sorry. Hmmm, this seems a different failure. The ABRT backtrace from comment #15 is indeed actually more helpful and seems to indicate that something is crashing in the garbage collector. bleah.
*** Bug 650146 has been marked as a duplicate of this bug. ***
Another idea for testing. This might be because escape analysis going wrong. Could someone test with the following added to /etc/eclipse.ini: -XX:-DoEscapeAnalysis
(In reply to comment #19) > Another idea for testing. This might be because escape analysis going wrong. > Could someone test with the following added to /etc/eclipse.ini: > -XX:-DoEscapeAnalysis Does not help.
Created attachment 458069 [details] crash after suggestion from comment #19 tried I've tried what Mark suggested in comment #19 and Eclipse still crashed.
(In reply to comment #21) > Created attachment 458069 [details] > crash after suggestion from comment #19 tried > > I've tried what Mark suggested in comment #19 and Eclipse still crashed. Did you get ABRT activated? If GUI didn't provide anything useful, try to attach here /var/spool/abrt/ccpp-*-24189/backtrace if you have one, please. Thank you
A backtrace. Don't know if it's useful, ABRT seemed to hang while creating it. http://www.bjorkevik.se/david/ccpp-1288964952-10714-backtrace
(In reply to comment #22) > (In reply to comment #21) > > Created attachment 458069 [details] [details] > > crash after suggestion from comment #19 tried > > > > I've tried what Mark suggested in comment #19 and Eclipse still crashed. > > Did you get ABRT activated? If GUI didn't provide anything useful, try to > attach here /var/spool/abrt/ccpp-*-24189/backtrace if you have one, please. > > Thank you Yes but I deleted that. And I've switched to the Sun/Oracle VM in the mean time to get some work done. But I'll try to reproduce: I've switched back to java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.x86_64, opened the C project. It went OK as it is now indexed. So I've launched C/C++ Code analysis and bang, crash again. So I'll do it twice, once with once without the change you suggested in comment #19 and post the info you asked for in comment #22.
Created attachment 458175 [details] in regards to comment #24: backtrace from crash without workaround from comment #19 in regards to comment #24: backtrace from crash without workaround from comment #19
Created attachment 458176 [details] in regards to comment #24: backtrace from crash with workaround from comment #19 applied in regards to comment #24: backtrace from crash with workaround from comment #19 (-XX:-DoEscapeAnalysis) applied
Created attachment 458184 [details] backtrace from remote website (In reply to comment #23) > A backtrace. Don't know if it's useful, ABRT seemed to hang while creating it. > > http://www.bjorkevik.se/david/ccpp-1288964952-10714-backtrace Just storing a local copy to bugzilla
*** Bug 650751 has been marked as a duplicate of this bug. ***
*** Bug 651008 has been marked as a duplicate of this bug. ***
*** Bug 651036 has been marked as a duplicate of this bug. ***
Denis and I have been working on narrowing down the problem, and we found the issue to be in compressed oops. hs17-11 turned them off, which is why the older OpenJDK package worked. hs17-10 (and hs19 which branched from it) has it on, and hence this bug which looks like a regression in hotspot but it isn't. Adding the following line to eclipse.ini should make it work again: -XX:-UseCompressedOops This is only a workaround of course. We're continuing to look into the actual issue/for a proper solution.
Yes it worked. :) At least, it's better than reverting back to sun/oracle jdk. Thanks a lot for your efforts. Considering the importance of this bug, I suggest adding a section about this bug in F14 Common Bugs section and including the current workaround for now. Thanks again
(In reply to comment #32) > Yes it worked. :) At least, it's better than reverting back to sun/oracle jdk. > Thanks a lot for your efforts. Considering the importance of this bug, I > suggest adding a section about this bug in F14 Common Bugs section and > including the current workaround for now. > > Thanks again Good point! I've added it to the wiki: https://fedoraproject.org/wiki/Common_F14_bugs#Eclipse_crashes_with_OpenJDK_when_using_CDT Thanks.
(In reply to comment #31) > Adding the following line to eclipse.ini should make it work again: > -XX:-UseCompressedOops > > This is only a workaround of course. We're continuing to look into the actual > issue/for a proper solution. Workaround works. Thank you.
*** Bug 651325 has been marked as a duplicate of this bug. ***
(In reply to comment #31) > Adding the following line to eclipse.ini should make it work again: > -XX:-UseCompressedOops +1 from me as well. Thanks for ability to have no excludes in yum.conf!
*** Bug 651260 has been marked as a duplicate of this bug. ***
Workaround works here too. Thanks
*** Bug 647578 has been marked as a duplicate of this bug. ***
*** Bug 649769 has been marked as a duplicate of this bug. ***
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1.Using eclipse CDT 2.Editing comments 3.
*** Bug 651875 has been marked as a duplicate of this bug. ***
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. start eclipse with CDT installed, and C++ projects 2. wait a bit, while the C++ indexer starts indexing 3.
eclipse-3.6.1-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/eclipse-3.6.1-4.fc14
I have pushed a build of eclipse with the eclipse.ini workaround in it for F14 that will shortly be available via updates-testing.
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Start eclipse with "-XX:-UseCompressedOops" work around 2. Edit file, including cut and paste 3. Eclipse crashes Comment ----- This is a duplicate of a current bug report. The only thing new is that the crash happened even though "-XX:-UseCompressedOops" was given upon startup.
(In reply to comment #46) > Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 > Architecture: x86_64 > OS Release: Fedora release 14 (Laughlin) > > > How to reproduce > ----- > 1. Start eclipse with "-XX:-UseCompressedOops" work around > 2. Edit file, including cut and paste > 3. Eclipse crashes > > > Comment > ----- > This is a duplicate of a current bug report. The only thing new is that the > crash happened even > though "-XX:-UseCompressedOops" was given upon startup. Can you please paste your /etc/eclipse.ini file?
(In reply to comment #46) > Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 > Architecture: x86_64 > OS Release: Fedora release 14 (Laughlin) > > > How to reproduce > ----- > 1. Start eclipse with "-XX:-UseCompressedOops" work around > 2. Edit file, including cut and paste > 3. Eclipse crashes > > > Comment > ----- > This is a duplicate of a current bug report. The only thing new is that the > crash happened even > though "-XX:-UseCompressedOops" was given upon startup. /etc/eclipse.ini: -startup plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.1.R36x_v20100810 -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile -vmargs -Xms128m -Xmx384m -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init> -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding -XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile -XX:CompileCommand=exclude,org/python/pydev/ui/filetypes/FileTypesPreferencesPage,getDottedValidSourceFiles
(In reply to comment #48) > (In reply to comment #46) ... > > /etc/eclipse.ini: > > -startup > plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar ... The above does not contain a -XX:-UseCompressedOops line. You need to add it there ... can you please do so and see if it fixes it?
(In reply to comment #47) > (In reply to comment #46) > > Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 > > Architecture: x86_64 > > OS Release: Fedora release 14 (Laughlin) > > > > > > How to reproduce > > ----- > > 1. Start eclipse with "-XX:-UseCompressedOops" work around > > 2. Edit file, including cut and paste > > 3. Eclipse crashes > > > > > > Comment > > ----- > > This is a duplicate of a current bug report. The only thing new is that the > > crash happened even > > though "-XX:-UseCompressedOops" was given upon startup. > > Can you please paste your /etc/eclipse.ini file? I had it on the command line. When I added -XX:-UseCompressedOops to the /etc/eclipse.ini file that seems to have resolved the problem. I was able to edit the code, then successfully compile and link.
*** Bug 643440 has been marked as a duplicate of this bug. ***
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Run Eclipse 2. Create c++ hello world project 3. Build project g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/Hello World.d" -MT"src/Hello\ World.d" -o"src/Hello World.o" "../src/Hello World.cpp" cc1plus: : -M -MM Comment ----- g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/Hello World.d" -MT"src/Hello\ World.d" -o"src/Hello World.o" "../src/Hello World.cpp" cc1plus: : -M -MM
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Open Eclipse 2. Choose workspace; watch it open 3. Once it is open, it does not respond and crashed Comment ----- I recently installed the C/C++ dev framework over my Eclipse for Java. I created a project on top of an existing folder with a few .cpp and .h files. I started being unstable, now it always crashes.
(In reply to comment #53) > Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 > Comment > ----- > I recently installed the C/C++ dev framework over my Eclipse for Java. > I created a project on top of an existing folder with a few .cpp and .h files. > I started being unstable, now it always crashes. Did you try the eclipse update with the workaround or attempt to perform the workaround yourself? See comment 44.
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Opended Eclipse for the first time on a new install with an existing workspace 2. Eclipse was scanning (something was going at the bottom right) 3. Oped a few files and then the screen dimmed then crash
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- I know it is reproducable in CDT projects/perspective (it happens randomly, but regularly). I have not been able to trigger it in non-CDT projects.
eclipse-3.6.1-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1.I open Eclipse Helios as a normal user (from icon or from bash shell) 2. Splash screen finish 3. Eclipse crash during C++ prespective loading Comment ----- I can open eclipse as root. I use Fedora 14 x64
Package: java-1.6.0-openjdk-1:1.6.0.0-44.1.9.1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Open Eclipse Helios as root (bash$ sudo eclipse) 2. Open a C++ Project (Default wizard Hello World) 3. Open the cpp file Comment ----- My OS is Fedora 14 x64, My JRE is 6.0_2-b20, etc. # JRE version: 6.0_20-b20 # Java VM: OpenJDK 64-Bit Server VM (19.0-b06 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.9.1 # Distribution: Custom build (Wed Oct 13 22:53:58 UTC 2010) # 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
Hello again, I update Fedora 14 x64, and now Eclipse Helios start (don't crash) but don't have the CDT Prespective loaded. I can't program in C++ :-( David Björkevik (com. 23), Mark Wielaard (Com. 17), Matej Cepl (Com. 14, 22) notice the ABRT crash. There is the bug [[https://bugzilla.redhat.com/show_bug.cgi?id=627680]] about it. I edit /etc/abrt/abrt.conf and change MaxCrashReport = 0 to remove the limit of reports (was the default 1000 MiB), and abrt dont crash again. My Java version is: {{{ [root@pudim ~]# java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.1) (fedora-44.1.9.1.fc14-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b06, mixed mode) }}} Cheers, Pedro
I send i attach the /etc/eclipse.ini and the information from: Eclipse Help Menu > About Eclipse Plataform > Instalation Details (button) > Configuration (tab) http://feupload.fe.up.pt/get/w5JD7at9YowMreW (eclipse.ini) http://feupload.fe.up.pt/get/ysKAsUS5wPNdSyn (Configuration details) > Cheers, > > Pedro
java-1.6.0-openjdk-1.6.0.0-49.1.9.2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-49.1.9.2.fc14
java-1.6.0-openjdk-1.6.0.0-49.1.9.2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Great. Thank you for all your efforts. But I think an update for eclipse-platform should be created to remove "-XX:-UseCompressedOops" from eclipse.ini Thanks again.
(In reply to comment #65) > Great. Thank you for all your efforts. But I think an update for > eclipse-platform should be created to remove "-XX:-UseCompressedOops" from > eclipse.ini > > Thanks again. It is being worked on and will be out soon.
eclipse-3.6.1-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/eclipse-3.6.1-5.fc14
eclipse-3.6.1-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
I see that you have this bug with openjdk but i've got the same with Oracle Java [mag@mag-lap eclipse-cpp]$ 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) [mag@mag-lap eclipse-cpp]$ javac -version javac 1.6.0_24 eclipse downloaded from the eclipse org (because of the repository rpm has +100MB dependencies, include openjdk too). Eclipse Platform Version: 3.6.2.r362_v20110210-9gF78Gs1FrIGnHDHWkEcopoN8AmxeZflGDGKQi Eclipse C/C++ Development Tools Version: 7.0.2.201102110609 adding -XX:-UseCompressedOops to te eclipse.ini seem to be resolving this issue.
(In reply to comment #69) > eclipse downloaded from the eclipse org (because of the repository rpm has > +100MB dependencies, include openjdk too). What's the problem with that? Is the overall size any smaller with the Sun JDK + upstream Eclipse EPP package?
(In reply to comment #69) > I see that you have this bug with openjdk but i've got the same with Oracle > Java That is not Fedora's problem.
(In reply to comment #71) > (In reply to comment #69) > > I see that you have this bug with openjdk but i've got the same with Oracle > > Java > > That is not Fedora's problem. On slightly more constructive note (and yes I think not using Fedora OpenJDK is silly ... it is as certified OpenJDK as the Oracle's one), file a ticket (I have no idea how, but there should be a way) with Oracle and mention them this bug report. I wonder whether they have included Fedora's patches.
I've posted this bug to the Oracle, about two weeks ago, but still no one answered. Why it's silly do not using OpenJDK? as far as I know form other websites not every applet work properly with it, and some of them (applets) I'm using.
(In reply to comment #73) > Why it's silly do not using OpenJDK? as far as I know form other websites not > every applet work properly with it, and some of them (applets) I'm using. Sorry, yes ... support for applets is not that great yet, sure. I forgot anybody cares about these yet ;).
(In reply to comment #73) > I've posted this bug to the Oracle, about two weeks ago, but still no one > answered. That's because it's a duplicate. The original bug (7002666) was fixed 3 months ago by this changeset: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4da76e32c0be > Why it's silly do not using OpenJDK? as far as I know form other websites not > every applet work properly with it, and some of them (applets) I'm using. If an applet is working with oracle's plugin but not with icedtea-web, *please* file a bug report. Don't just go using another jdk, otherwise we get into situations like this and we can't help you. So, if you could send me a list of applets that don't work for you, that would be great, and we'll look into them.
Actually, please post a list of non-working applets to a single bug if need be so that everyone can see it, rather than sending to a specific email address.
With the proprietary JDK, the only way to get things fixed is to ask Oracle nicely. That's what you get with proprietary software. The fix for this is in OpenJDK as shown in Denis' link above. It was created by Tom Rodriguez, a HotSpot engineer at Oracle so they are aware of the issue. I then backported it, first to IcedTea, and then to OpenJDK6. I have no idea why they haven't also included it in their builds but that's something you need to take up with them. As you've found, there is a workaround of turning off compressed oops as we originally used to work around the issue. You are welcome to apply that locally but it is unfair to apply this generally in the Eclipse package as the accompanying OpenJDK package works fine. The issue only occurs when using a JDK which is not part of Fedora. As mentioned above, if you are having issues with IcedTea or IcedTea-Web (the plugin & NetX component), you need to report them. Switching to another JDK and then making dismissive comments about OpenJDK doesn't help anyone. Depending on how long ago you stopped using OpenJDK, you may even find that the issues have been fixed in your absence.
ok, when I have some time I'll do some test and post list of not working apps and applets.
A better way to work around it would probably to add "-vmargs -XX:CompileCommand=exclude,java/lang/reflect/Array,newInstance" to the eclipse launcher (or just add the compilation exclusion to eclipse.ini). That way you don't turn off compressed oops for everything. And thanks in advance for the broken applet list :-) (but like Andrew said you should probably try them with a recent icedtea6+icedtea-web: many of the problems are likely to have been solved).
adding it to eclipse.ini (and excluding
sorry, but I found shortcut to "save changes" probably ctrl+space ;] adding it to eclipse.ini (and excluding -XX:-UseCompressedOops) results in Unrecognized option: -vmargs Could not create the Java virtual machine. ----- because of doubled -vmargs, with one everything seem to be working correctly