why does trying to attach to myself crash my vm?

Question

running the following code works fine on macos (sun jdk 1.8.0_51), but crashes every time with a thread dump on centOS (sun jdk 1.8.0 101) when it comes to attaching to itself, while succeeding to attach any other visible VM:

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;

public class Test {

    public static void main(String[] args) throws Exception {
        for(VirtualMachineDescriptor vmd : VirtualMachine.list()) {
            VirtualMachine vm = VirtualMachine.attach(vmd);
        }
    }

}

the thread dump:

"Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007fbb780bf000 nid=0x28a0 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007fbb780bc000 nid=0x289f runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fbb780ba000 nid=0x289e runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fbb780b7000 nid=0x289d runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fbb780b6000 nid=0x289c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fbb78082800 nid=0x289b in Object.wait() [0x00007fbb62eed000]
   java.lang.Thread.State: WAITING (on object monitor)
               at java.lang.Object.wait(Native Method)
               - waiting on <0x00000000d6608ee0> (a java.lang.ref.ReferenceQueue$Lock)
               at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
               - locked <0x00000000d6608ee0> (a java.lang.ref.ReferenceQueue$Lock)
               at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
               at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fbb7807e000 nid=0x289a in Object.wait() [0x00007fbb62fee000]
   java.lang.Thread.State: WAITING (on object monitor)
               at java.lang.Object.wait(Native Method)
               - waiting on <0x00000000d6606b50> (a java.lang.ref.Reference$Lock)
               at java.lang.Object.wait(Object.java:502)
               at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
               - locked <0x00000000d6606b50> (a java.lang.ref.Reference$Lock)
               at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007fbb78008000 nid=0x2894 waiting on condition [0x00007fbb7f307000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
               at java.lang.Thread.sleep(Native Method)
               at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:100)
               at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:78)
               at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:250)
               at Test.main(Test.java:10)

"VM Thread" os_prio=0 tid=0x00007fbb78076800 nid=0x2899 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fbb7801d800 nid=0x2895 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fbb7801f800 nid=0x2896 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fbb78021000 nid=0x2897 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fbb78023000 nid=0x2898 runnable

"VM Periodic Task Thread" os_prio=0 tid=0x00007fbb780c2000 nid=0x28a1 waiting on condition

JNI global references: 19

Heap
PSYoungGen      total 37888K, used 9835K [0x00000000d6600000, 0x00000000d9000000, 0x0000000100000000)
  eden space 32768K, 30% used [0x00000000d6600000,0x00000000d6f9ad98,0x00000000d8600000)
  from space 5120K, 0% used [0x00000000d8b00000,0x00000000d8b00000,0x00000000d9000000)
  to   space 5120K, 0% used [0x00000000d8600000,0x00000000d8600000,0x00000000d8b00000)
ParOldGen       total 86016K, used 0K [0x0000000083200000, 0x0000000088600000, 0x00000000d6600000)
  object space 86016K, 0% used [0x0000000083200000,0x0000000083200000,0x0000000088600000)
Metaspace       used 3451K, capacity 4728K, committed 4864K, reserved 1056768K
  class space    used 382K, capacity 424K, committed 512K, reserved 1048576K

Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
               at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
               at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:78)
               at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:250)
               at Test.main(Test.java:10)

can anyone explain?

it could be a bug. I would try the latest version of Java 8. — Peter Lawrey, Nov 08 '16 at 16:26
@PeterLawrey same result with 1.8.0_111-b14, 1.8.0_51-b16, 1.7.0_80-b15 ... all around more or less thread dump — rmalchow, Nov 08 '16 at 16:43
it should work without additional permissions. Do you have some firewall? — Peter Lawrey, Nov 08 '16 at 16:46
@PeterLawrey no firewall, also ... this is not via TCP ... strange thing though, as root, this works. SELinux is permissive, nothing in audit log. — rmalchow, Nov 08 '16 at 17:11
I’m confused. In the dump, the `main` thread is sleeping at `LinuxVirtualMachine.java:100`, but at the end there is a stack trace of an exception throw from `LinuxVirtualMachine.java:106`, which suggests that it has advanced past that point. So there’s no actual sign of a crash, but just an exception. — Holger, Nov 08 '16 at 18:12
Btw. is there any proof that it is its own virtual machine, on which it fails? — Holger, Nov 08 '16 at 18:14
@Holger well, there are a bunch of other VMs running, eclipse for one, 2 jsonsoles, a kafka, a tomcat ... all running as the same user, and enumerating and attaching without a problem. only when it tries to attach to itself, i get the core dump from the vm, and, suprisingly, a stacktrace that says that the VM is not responding (output, but not necessarily generated after the core dump). — rmalchow, Nov 08 '16 at 20:09
I described [here](http://stackoverflow.com/questions/26140182/running-jmap-getting-unable-to-open-socket-file/35963059#35963059) how Dynamic Attach works. Stack trace is apparently printed in response to SIGQUIT sent by `VirtualMachine.attach`. No AttachListener thread has been started. This can happen if 1) -XX:+DisableAttachMechanism is enabled, or 2) the VM fails to find `.attach_pid` file in current working directory or in /tmp. Can you manually check if `.attach_pid` file is created when you invoke `VirtualMachine.attach`? — apangin, Nov 09 '16 at 00:10
@apangin: good point. Does using the `QUIT` signal for attaching imply that it also won’t work when `-Xrs` has been specified? I mean, *if* `-Xrs` disables the use of this signal as documented. Under Windows, the implementation doesn’t behave as documented, i.e. thread dumps still work when `-Xrs` has been specified (I noticed when answering [this question](http://stackoverflow.com/q/40244888/2711488)). — Holger, Nov 09 '16 at 10:03
@Holger If `-Xrs` is specified, `AttachListener` thread is created beforehand during VM initialization. Particularly, UNIX socket for communication with tools is also created beforehand, so that Attach mechanism could connect to the socket without sending signals. Dynamic Attach works differently on Windows. It relies on CreateRemoteThread API to execute commands directly in the context of remote Java process. — apangin, Nov 09 '16 at 10:53
@apangin any suggestion how i would check for that file? the time between calling attach() and the core dump is pretty short ... however, since it crashes for a regular user, (i tried different ones), but doesn't crash for super users, i also suspect it might be in some way permission related ... — rmalchow, Nov 09 '16 at 14:47
I guess VM does not really crash. It looks like standard SIGQUIT handler is called after VM's handler for some reason. By default SIGQUIT handler writes a coredump if `ulimit -c` is non-zero. Try setting `ulimit -c 0`. — apangin, Nov 09 '16 at 15:53

why does trying to attach to myself crash my vm?

0 Answers0