JDK-8073688 : Infinite loop reading types during jmap attach.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-02-23
  • Updated: 2015-09-29
  • Resolved: 2015-03-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u85Fixed 8u60Fixed 9 b56Fixed
Related Reports
Relates :  
JDK-8074320 - Solaris packages for jdk7u create unnecessary link in jre/lib/sparc to jre/lib/sparc/client/libjvm
Description
Attaching jstack to a process can result in an infinite loop, as it reads type definitions, such as:

Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Continuing.
Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Continuing.
Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Continuing.
Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Continuing.
Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Continuing.
Warning: the type "jboolean" (declared in the remote VM in VMStructs::localHotSpotVMTypes) had its size declared as -158127939785850880 twice. Conti...

The type-reading loop, if reading bad data, can loop forever: we could implement a limit in that read to protect ourselves.
Comments
LD_DEBUG=files,libs shows the second libjvm is not opened directly: libverify's RUNPATH is ORIGIN, and it pulls in a libjvm from the same directory as itself (JDK/jre/lib/sparc). BUT a libjvm is already loaded from jre/lib/sparc/server/libjvm.so. An LD_LIBRARY_PATH setting to find jre/lib/sparc/server first should also avoid the problem.
27-02-2015
This problem reproduces with a trivial app on the machine where it was first observed, but not on some other machines/JDK installs tested. Problematic runs show two libjvms mapped in e.g.: $ pldd 38120 | grep jvm /usr/jdk/instances/jdk1.7.0/jre/lib/sparc/server/libjvm.so /usr/jdk/instances/jdk1.7.0/jre/lib/sparc/client/libjvm.so Problematic installation: /usr/jdk/instances/jdk1.7.0/jre/lib/sparc contains libjvm.so -> client/libjvm.so A test installation from the RE tar files (not solaris packages) did not contain that link: Create that link, create the problem. Two libjvm.so files "loaded" confuses the SA: it is resolving symbols correctly, and finding addresses, but from which .so? Deleting the symlink from jdk1.7.0/jre/lib/sparc should avoid the problem.
26-02-2015