com.soleil.outils.attacher.AttachNotSupportedException: Impossible d'ouvrir le fichier de socket: processus cible ne répond pas ou HotSpot VM n'est pas chargé

- Je obtenir AttachNotSupportedException lors de l'exécution de jmockit tests sur linux (ubuntu 64 bits). Version de Java est 1.7.0_51. Ce JDK est à partir d'Oracle. Les Tests sont exécutés à l'aide de ant(qui n'est probablement pas pertinent)

Voir la trace de la pile.

[junit] 
[junit] java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
[junit]     at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:89)
[junit]     at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:54)
[junit]     at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
[junit]     at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:136)
[junit]     at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:169)
[junit]     at junit.framework.TestResult.<clinit>(TestResult.java:15)
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:356)
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1165)
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1016)
[junit] Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
[junit]     at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
[junit]     at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:79)
[junit]     ... 8 more
[junit] Exception in thread "main" java.lang.ExceptionInInitializerError
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:356)
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1165)
[junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1016)
[junit] Caused by: java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
[junit]     at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:89)
[junit]     at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:54)
[junit]     at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
[junit]     at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:136)
[junit]     at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:169)
[junit]     at junit.framework.TestResult.<clinit>(TestResult.java:15)
[junit]     ... 3 more
[junit] Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
[junit]     at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
[junit]     at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:79)
[junit]     ... 8 more
[junit] Running chs.caf.cap

Il semble être lié à AttachNotSupportedException lors de l'exécution de jMockit tests sur IBM JRE. Ceci, toutefois, est sur IBM jre.

InformationsquelleAutor Jayan | 2014-08-22
  1. 18

    Contourner pour l'instant.

    Ajoutant '-XX:+StartAttachListener' à l'argument jvm résolu le problème.

    Un problème similaire est abordée ici à https://code.google.com/p/jmockit/issues/detail?id=136 et http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-October/006098.html (qui parle d'une possible régression dans jdk7 construire)

    • Apparemment, c'est un bug dans l'attachement de l'API de mise en œuvre dans cette version de l'Oracle JRE pour Linux. Il est probablement déjà fixé dans 1.7.0_60 et au-dessus.
    • En fait, c'était toujours un problème pour moi dans 1.8.0_131 sur Linux
    InformationsquelleAutor Jayan
  2. 12

    Ma réponse sera un peu non, mais j'ai eu le même problème lors de la tentative de vidage de threads à l'aide de jcmd. J'étais même message d'erreur même si je courais jcmd en vertu de la racine de l'utilisateur.

    Vous avez besoin pour exécuter jcmd <pid> Thread.dump en vertu de la même utilisateur que java processus a, sinon vos connexions seront supprimées. Java n'a pas de soins si vous êtes racine ou pas.

    Donc en gros:

    sudo -u <java_process_user> jcmd <pid> Thread.dump
    • j'ai essayé, mais ça m'a donné Permission denied
    InformationsquelleAutor message
  3. 1

    Comme @bbarker, j'ai eu la même erreur, mais sur JDK 1.8.0_161 à l'aide de la sous-système Linux dans Windows 10 ("Bash sur Ubuntu que sur Windows"). La configuration du plugin Surefire avec l'argument JVM mentionné ci-dessus fixe le problème pour moi aussi:

        <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<argLine>-XX:+StartAttachListener</argLine>
</configuration>
</plugin>

    Exécuter les tests de "normal" invite de commande Windows fonctionne sans ci-dessus, si.

    InformationsquelleAutor Erik Finnman