Community
Participate
Working Groups
Platform: RedHat Enterprise Linux 4.0 WS update 1 Running on a VMWare image. This was reproduced on RHEL AS 4 u1 running on a separate VMWare system. The hang appears to occur during a disk access after opening a File dialog, even if the file dialog is cancelled. Install Eclipse 3.1 on RedHat Ent Linux 4 update 1 Steps to Reproduce: From a console (so you can see the message), start Eclipse... New->Project, name: test New->File name: test1 File->Open, cancel the open dialog New->File name: test2 Result: Eclipse will hang (no response). In the Linux console, it says: JVMDG217: Dump Handler is Processing Signal 11 - Please wait. It will hang when running as a regular user and as root. === Java version 1.4.2 Java(TM) 2 Runtime Environment, SE 1.4.2 Classic VM (build 1.4.1, J2RE 1.4.2 IBM build cxia32142-10050609 ======== !ENTRY org.eclipse.core.resources 2 10035 2005-09-30 15:15:30.854 !MESSAGE A workspace crash was detected. The previous session did not exit normally. !SESSION 2005-09-30 15:34:25.566 ---------------------------------------------- - eclipse.buildId=I20050627-1435 java.fullversion=J2RE 1.4.2 IBM build cxia32142-20050609 (JIT enabled: jitc) BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86
Can you provide a stack trace of the process when it is hung? To get a stack dump, invoke "kill -3 <pid>" from the command line, where <pid> is the id of the Java process (ps -aux| grep java).
"kill -3 <pid>" before the hang will generate a stack dump, but "kill -3 <pid>" after the hang does not create a stack dump. Since the original message is "Dump Handler is Processing Signal 11 - Please wait." it probably is stuck trying to do the first dump.
It also appears that this problem exists in Eclipse 3.1.1.
I see this problem with the following JVMs (from IBM): build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20041210 build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20050929 I DO NOT see this problem with the following JVM (from Sun): Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05) For the meanwhile, people who experience this problem should consider taking advantage of the -vm argument when launching eclipse and getting the Sun JVM. :)
I'm going to close this, since it's a hang in the VM itself. The hang is not reproducible on either the Sun VM, or the IBM J9SC VM.
This problem potentially impacts any IBM product that runs on Eclipse and ships an IBM JRE. Is it possible for the Eclipse team to file a bug against IBM Java? I would open the Java bug myself except I don't have enough detail to put it in. We do not have a javacore file, and I'm not familiar with the Eclipse code that exposes the problem.
On our RedHat Enterprise Linux 4 with Update 1 this also fails with -vmargs - Xj9. > eclipse -vmargs -Xj9 File-> Open... Cancel File-> New... Enter file name Fails with Signal 11.
You may want to make sure that you have a J9 enabled JVM as the default IBM JVMs do not include J9. You can check the version information (and ensure that it is a J9VM) as follows: $ java -Xj9 -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 2.2) IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux x86-32 j9xia32142-20050929 (JIT enabled) J9VM - 20050915_1101_lHdSMR JIT - r7_level20050909_1801) $ java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20050929 (SR3) (JIT enabled: jitc))
You are correct... "java -Xj9 -version" answers with the classic message. I'll try another JVM. Thanks.
I get the same: JVMDG217: Dump Handler is Processing Signal 11 - Please Wait. ...but when trying to use a workspace copied over from a working Debian environment to a Fedora Core 4 with today's updates with exactly the same JDK (IBMJava2-SDK-142.tgz) and Eclipse 3.1.2. Seems to crash around "org.eclipse.team.cvs.core". strace shows: stat64("/usr/local/bin/java", {st_mode=S_IFREG|0755, st_size=43163, ...}) = 0 stat64("/usr/local/bin/java", {st_mode=S_IFREG|0755, st_size=43163, ...}) = 0 getpid() = 21258 shmget(21258, 16384, IPC_CREAT|0666) = 589836 stat64("/usr/local/lib/eclipse/startup.jar", {st_mode=S_IFREG|0664, st_size=32567, ...}) = 0 stat64("/etc/gre.conf", 0xbfd914dc) = -1 ENOENT (No such file or directory) stat64("/etc/gre.d/gre.conf", {st_mode=S_IFREG|0644, st_size=42, ...}) = 0 open("/etc/gre.d/gre.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=42, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f94000 read(3, "[1.7.12]\nGRE_PATH=/usr/lib/mozil"..., 4096) = 42 close(3) = 0 munmap(0xb7f94000, 4096) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f80708) = 21259 wait4(-1, JVMDG217: Dump Handler is Processing Signal 11 - Please Wait. Once I CTRL-C after the Signal 11, this is left-over: rngadam 10831 1 44 15:43 pts/2 00:04:08 /usr/local/bin/java -Xms40m -Xmx256m -jar /usr/local/lib/eclipse/startup.jar -os linux -ws gtk -arch x86 -launcher /usr/local/lib/eclipse/eclipse -name Eclipse -showsplash 600 -exitdata 50006 -vm /usr/local/bin/java -vmargs -Xms40m -Xmx256m -jar /usr/local/lib/eclipse/startup.jar rngadam 10840 10831 0 15:43 pts/2 00:00:00 [eclipse] <defunct> [rngadam@localhost ~]$ java -version java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20060120 (SR4) (JIT enabled: jitc)) However, the environment loads up correctly if I use an empty workspace and I can't reproduce the original reporter problem. How could I get more information on where/why the problem occurs?
*** Bug 130973 has been marked as a duplicate of this bug. ***
This bug report is a bit confused, and should be moved to SWT. A signal 11 is a SIGSEGV and points to bug in SWT. As soon as you see this message on the console, the app has crashed. While any hangs after this point may be VM bugs, fixing them won't stop the app from crashing, so it doesn't really matter much. If the bug is not reproducable with the Sun VM, there may still be a bug in SWT. SEGVs occur when accessing invalid memory, and so switching the VM may helpfully avoid the crash, but while corrupting some memory and moving the bug somewhere else. To the original reporter, is it the native file dialog which you are interacting with when the crash occurs? Regarding the strace output in comment #10, you are only looking at the strace output from the Eclipse executable itself and not the Java VM it spawns. Use strace -f to also strace the forked VM process if you want to get hints about when the crash occurs. I do not think the strace output will be very useful though.
Z, can you see if this still happens with 3.2?
(In reply to comment #13) > Z, can you see if this still happens with 3.2? This problem still happens on Eclipse 3.2 with the same errors
This appears to be a problem in the JVM, and a bug has been reported to the VM vendor. Further details will be posted here when they come available.
I was able to reproduce this with IBM jre1.4.2 but with no others, as has been reported. This is a VM problem, so there is not an swt issue to be fixed.
