Community
Participate
Working Groups
I am receiving core dumps repeatably with N20050505, 3.1M7, and 3.1RC1 binary builds for linux-gtk-ppc when attempting to run on an IBM 1.4.2 JDK on PowerPC Linux. I have tried multiple copies of the JDK to ensure that it was not a particular issue with the JDK. The machine is an Apple PowerBook G4 running Debian unstable on a 2.6.11.10 kernel: Machine Information $ uname -a Linux case 2.6.11.10barryh.1 #1 Tue May 24 12:44:30 EDT 2005 ppc GNU/Linux $ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1666MHz revision : 1.2 (pvr 8003 0102) bogomips : 1658.88 machine : PowerBook5,6 motherboard : PowerBook5,6 MacRISC3 Power Macintosh detected as : 287 (Unknown Intrepid-based) pmac flags : 00000008 L2 cache : 512K unified memory : 2048MB pmac-generation : NewWorld Attempted Launch Transcript $ ./eclipse -consolelog -debug -vmargs -Dosgi.locking=none Start VM: /home/barryh/IBMJava2-ppc-142/jre/bin/java -Dosgi.locking=none -jar /home/barryh/eclipse/3.1RC1/eclipse/startup.jar -os linux -ws gtk -arch ppc -launcher /home/barryh/eclipse/3.1RC1/eclipse/eclipse -name Eclipse -showsplash 600 -exitdata 288019 -consolelog -debug -vm /home/barryh/IBMJava2-ppc-142/jre/bin/java -vmargs -Dosgi.locking=none -jar /home/barryh/eclipse/3.1RC1/eclipse/startup.jar barryh@case:~/scripts$ Install location: file:/home/barryh/eclipse/3.1RC1/eclipse/ Configuration file: file:/home/barryh/eclipse/3.1RC1/eclipse/configuration/config.ini loaded Configuration location: file:/home/barryh/eclipse/3.1RC1/eclipse/configuration/ Framework located: file:/home/barryh/eclipse/3.1RC1/eclipse/plugins/org.eclipse.osgi_3.1.0.jar Framework classpath: file:/home/barryh/eclipse/3.1RC1/eclipse/plugins/org.eclipse.osgi_3.1.0.jar Splash location: /home/barryh/eclipse/3.1RC1/eclipse/plugins/org.eclipse.platform_3.1.0/splash.bmp runCommand: </home/barryh/eclipse/3.1RC1/eclipse/eclipse><-name><Eclipse><-showsplash><600></home/barryh/eclipse/3.1RC1/eclipse/plugins/org.eclipse.platform_3.1.0/splash.bmp> Debug options: file:/home/barryh/scripts/.options not found JVMDG217: Dump Handler is Processing Signal 4 - Please Wait. JVMDG303: JVM Requesting Java core file JVMDG304: Java core file written to /home/barryh/scripts/javacore.20050530.183312.18510.txt JVMDG215: Dump Handler has Processed Exception Signal 4. This machine contains all the necessary libraries to run SWT applications as shown in the documentation (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/faq.html#gtkstartup). The machine is able to successfully complete a build of Eclipse 3.1RC1 from source, including the -compilelibs directive to recompile the executable and the SWT libs. (As a side note, the libxt-dev package in Debian was required in order to have the header file /usr/X11R6/include/X11/Intrinsic.h, which is invoked by the swt header file <ibm_jdk_home>/include/jawt_md.h, reported in a separate bug.) These binaries ran successfully on another PowerPC Linux machine that I no longer have. One of the core dump files will subsequently be attached to the bug report. Thanks in advance for your consideration of this issue.
Created attachment 22002 [details] IBM JDK core dump from attempted launch of the JDT This is the core dump mentioned in the initial report of the bug.
The crash appears to be a problem with the VM and not with anything eclipse is doing: there is only Java code in the stack and no native code. If you are experiencing these sort of VM dumps with various VMs, could it be that they are compiled with a different ABI from your system's version of libc, or some other fundamental problem like that? Have you been able to successfully run other Java applications with these JVMs on this system?
(In reply to comment #2) > Have you been able to successfully > run other Java applications with these JVMs on this system? Yes, Tomcat is currently running without issue on this machine. I currently have no other Java desktop apps, nor SWT apps to be specific, running on this machine. I agree that the issue seems to be with a lib the VM is depending upon, but I have no idea what that may be.
try to start eclipse with -vmargs -Xj9 if the VM supports it.
(In reply to comment #4) > try to start eclipse with -vmargs -Xj9 if the VM supports it. I attempted to launch with that argument, and the result is the same. Thanks for the suggestion. One additional suggestion Billy Biggs had made was that the IBM JDK is attempting to access a particular X lib that may be different from the version of that lib that is currently installed. Any pointers on how to try and isolate something like that would be greatly appreciated.
I don't think this has anything to do with any X libraries as there are none mentioned in the VM dump. The only thing there is glibc and some related libraries.
(In reply to comment #6) > I don't think this has anything to do with any X libraries as there are none > mentioned in the VM dump. The only thing there is glibc and some related libraries. My mistake; I misquoted Billy on that. Sorry.
Barry any chance on that with newer version of eclipse and VM?
(In reply to comment #8) Pascal, that is no longer my primary architecture, but I will get it up to date and try it out this weekend. Would that be alright?
Sorry for the late answer, but yes it would be helpful if you could check.
Closing; this looks like a VM bug.
