Community
Participate
Working Groups
Build Identifier: 20110505-1223 During editing sessions in CDT (Both Helios and Indigo) Eclipse will become completely unresponsive resulting in a force quit and loss of any unsaved changes. These issues do NOT seem to happen when I use the 32 bit Carbon version of Eclipse. The java version is the latest for OS X 10.6.8: java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) Client VM (build 19.1-b02-334, mixed mode) Reproducible: Sometimes Steps to Reproduce: I can not pin down the exact cause of the issue. At first it seemed to happen mostly when I was saving the file but that may have been a red herring.
Created attachment 195751 [details] Stack Trace During the lock up
Could you attach a java stack trace? You should have the jstack command available if you open Terminal. This is most likely a SWT bug.
Tried jstack and got this: 506:[mjackson@ferb2:~]$ jps 21791 12278 22427 Jps 507:[mjackson@ferb2:~]$ jstack -F -l 12278 Attaching to process ID 12278, please wait... attach: task_for_pid(12278) failed (5) Error attaching to process: Error attaching to process, or no such process pid 12278 is the Eclipse process as verified with Top and Activity Monitor. Not sure what else to do.
Created attachment 195869 [details] Contains the Java Thread Stack Trace
(In reply to comment #4) > Created attachment 195869 [details] > Contains the Java Thread Stack Trace Unfortunately, this backtrace isn't from Eclipse. It looks like it's from some other AWT based application. On Mac OS X you should be able to run Eclipse from a termina like: /Applications/eclipse3.7M7/eclipse Then jps and jstack should do the right thing...
Well I now launch eclipse from the command line using just this: /Users/mjackson/Downloads/eclipse/Eclipse.app/Contents/MacOS/eclipse but when eclipse finally locked up again (took a while) I tried jstack and I get the following error: 502:[mjackson@ferb2:~]$ jps 13419 Jps 877 505:[mjackson@ferb2:~]$ jstack -F -l 877 Attaching to process ID 877, please wait... attach: task_for_pid(877) failed (5) Error attaching to process: Error attaching to process, or no such process So I have no idea how to get the java stack trace which means I am going to give up on trying to figure this bug out. If someone wants to mark it as unresolved and close it, that is fine with me. I'll continue to use the Carbon builds until those are no longer available and then I'll try it again.
(In reply to comment #6) > So I have no idea how to get the java stack trace which means I am going to > give up on trying to figure this bug out. If someone wants to mark it as > unresolved and close it, that is fine with me. I'll continue to use the Carbon > builds until those are no longer available and then I'll try it again. Let's not close this, I will try to reproduce first. Sorry, I haven't used CDT on Mac OS for a while and haven't had the time to try and reproduce it yet.
(In reply to comment #6) > 505:[mjackson@ferb2:~]$ jstack -F -l 877 Whta's jstack -F -l ? When I just do: jstack <pid> (without other arguments) it works fine.
If you do a jstack with no arguments you get this: 504:[mjackson@ferb2:~]$ jstack Usage: jstack [-l] <pid> (to connect to running process) jstack -F [-m] [-l] <pid> (to connect to a hung process) jstack [-m] [-l] <executable> <core> (to connect to a core file) jstack [-m] [-l] [server_id@]<remote server IP or hostname> (to connect to a remote debug server) Options: -F to force a thread dump. Use when jstack <pid> does not respond (process is hung) -m to print both java and native frames (mixed mode) -l long listing. Prints additional information about locks -h or -help to print this help message Which is why I used the "-F" argument since eclipse was hung. I did verify that I can do: jstack <pid> while eclipse is NOT hung I can get the stack traces. So not sure what is going wrong. Mike J
Hi, Just to confirm, I also can't get a stacktrace at the time eclipse hangs. The error message printed by jstack is the same. I am still not sure when it happens, can't find a relation with anything I do.
I don't think CDT has anything to do with the lockups. It's either a JVM or SWT bug. Could you try adding -Xint to the vmargs in eclipse.ini? This disables the JIT compiler and if it solves the lockups we likely found the culprit.
*** Bug 345138 has been marked as a duplicate of this bug. ***
I haven't added the Xint to my vmargs yet, but will do the next time I need to use CDT. But, at the moment I am using the JDT and don't see any lockups.
Over the last few days I have used the CDT with -Xint, and no lock until now. So it does seem to be related to the JIT compiler. Does this help? Or is there something more needed?
(In reply to comment #14) > Over the last few days I have used the CDT with -Xint, and no lock until now. > So it does seem to be related to the JIT compiler. > > Does this help? Or is there something more needed? We cannot fix the JVM, so I am closing this as NOT_ECLIPSE. Workarounds are: - Use a 32 bit version - Disable the JIT compiler with option -Xint
Makes sense, but as I stated earlier, how come this doesn't happen when using the JDT? Is there some special case used in CDT which triggers this? If it is only the VM I would expect the same issue with other plugins..
(In reply to comment #16) > Makes sense, but as I stated earlier, how come this doesn't happen when using > the JDT? Is there some special case used in CDT which triggers this? > > If it is only the VM I would expect the same issue with other plugins.. If your Java code breaks the JVM, who is the culprit? We have had numerous crashes because of a hotspot compiler bug (bug 333227). Although this seems to affect only CDT, it is not CDT's fault. BTW, the Java version mentioned in comment 0 does contain this hotspot bug, so this might even be the same issue with different manifestation. It might make sense to try the same workaround: -XX:-UseCompressedOops
> If your Java code breaks the JVM, who is the culprit? I completely agree it is the VM, just curious about it, and if there might be a (code) workaround for it. > BTW, the Java version mentioned in comment 0 does contain this hotspot bug, so > this might even be the same issue with different manifestation. It might make > sense to try the same workaround: -XX:-UseCompressedOops Will try this as well, I have the feeling not using the jit compiler makes it slower at some points. So maybe this is a better workaround.
*** Bug 353026 has been marked as a duplicate of this bug. ***
*** Bug 363672 has been marked as a duplicate of this bug. ***
I am not sure how much this will help, but maybe someone with more knowledge can make sense of it. Recently the laptops in my lab were upgraded to the late 2011 Macbook Pros. Prior to the upgrade everyone was running Eclipse Indigo C/C++ SR1 64 bit on Lion with no issues. We installed the same version of Eclipse on the new laptop with all the latest OS patches, and saw the same bug described in the original post. The only difference, with respect to software, between the old laptops and the new is the old laptops were upgraded through the various versions of Snow Leopard to Lion (and in some cases from Leopard). My laptop had been upgrade from OS X 10.6.0, through each patch, to 10.7.2. The only reason I can think of that Eclipse worked on the old laptops and not on the new is some files were left on the hard drive from an old version of the Java VM that has since been dropped.
I was able to resolve the issue by installing "Java for Mac OS X Developer Preview 2012-001." In Java Preferences, it shows up as "Java SE 6" version "1.6.0_30-b12-409." I have been using this version with the x86_64 version of Eclipse for several days without issue.
