We Keep Coding

Can't get a Java heapdump from a docker container

My Java process is stuck and hogging a lot of CPU on the VM. I am trying to get to the root of the issue by getting a heapdump. This process is running in a docker container. I am getting into the container and running a jmap -F -dump:format=b,file=/tmp/heapdump.bin 6 as root user. But I still get java.lang.reflect.InvocationTargetException.
I used jmap -F to get over this exception - com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
I referenced the this post to make modifications to my query - Running jmap getting Unable to open socket file,
I have tried both jmap and jcmd queries, but got the same results.
Can someone please help here?
# jmap -F -dump:format=b,file=/tmp/heapdump.bin 6
Attaching to process ID 6, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.111-b14
Dumping heap to /tmp/heapdump.bin ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: java.lang.InternalError: Metadata does not appear to be polymorphic
at sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:278)
at sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
at sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:68)
at sun.jvm.hotspot.memory.DictionaryEntry.klass(DictionaryEntry.java:71)
at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:66)
at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190)
at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:954)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:427)
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)

I too faced this issue with openjdk8 alpine. Worked fine on upgrading base image to openjdk:17-jdk-alpine

Scala under MSys2 - failure to initialize terminal

My environment is Windows 10 x64/Scala 2.11.7/Msys2 latest.
When running Scala from MSys2 console, I see the following:
$ scala
[ERROR] Terminal initialization failed; falling back to unsupported
java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)
at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:204)
at jline.WindowsTerminal.init(WindowsTerminal.java:82)
at jline.TerminalFactory.create(TerminalFactory.java:101)
at jline.TerminalFactory.get(TerminalFactory.java:158)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:229)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:221)
at jline.console.ConsoleReader.<init>(ConsoleReader.java:209)
at scala.tools.nsc.interpreter.jline.JLineConsoleReader.<init>(JLineReader.scala:61)
at scala.tools.nsc.interpreter.jline.InteractiveReader.<init>(JLineReader.scala:33)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at scala.tools.nsc.interpreter.ILoop$$anonfun$scala$tools$nsc$interpreter$ILoop$$instantiate$1$1.apply(ILoop.scala:865)
at scala.tools.nsc.interpreter.ILoop$$anonfun$scala$tools$nsc$interpreter$ILoop$$instantiate$1$1.apply(ILoop.scala:862)
at scala.tools.nsc.interpreter.ILoop.scala$tools$nsc$interpreter$ILoop$$mkReader$1(ILoop.scala:871)
at scala.tools.nsc.interpreter.ILoop$$anonfun$15$$anonfun$apply$8.apply(ILoop.scala:875)
at scala.tools.nsc.interpreter.ILoop$$anonfun$15$$anonfun$apply$8.apply(ILoop.scala:875)
at scala.util.Try$.apply(Try.scala:192)
at scala.tools.nsc.interpreter.ILoop$$anonfun$15.apply(ILoop.scala:875)
at scala.tools.nsc.interpreter.ILoop$$anonfun$15.apply(ILoop.scala:875)
at scala.collection.immutable.Stream.map(Stream.scala:418)
at scala.tools.nsc.interpreter.ILoop.chooseReader(ILoop.scala:875)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1$$anonfun$apply$mcZ$sp$2.apply(ILoop.scala:916)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:916)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:911)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:911)
at scala.reflect.internal.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:97)
at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:911)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:74)
at scala.tools.nsc.MainGenericRunner.run$1(MainGenericRunner.scala:87)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:98)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
Welcome to Scala version 2.11.7 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_79).
Type in expressions to have them evaluated.
Type :help for more information.
scala>
When running it from cmd.exe, it works as expected. To debug the issue, I tried the following Scala program:
object Test extends App {
println(org.fusesource.jansi.internal.WindowsSupport.getConsoleMode)
}
When run from Msys2, it produces the following error:
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi in java.library.path]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.Kernel32.<clinit>(Kernel32.java:37)
at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)
at Test$.delayedEndpoint$Test$1(Test.scala:5)
at Test$delayedInit$body.apply(Test.scala:1)
at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.App$$anonfun$main$1.apply(App.scala:76)
at scala.collection.immutable.List.foreach(List.scala:381)
at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
at scala.App$class.main(App.scala:76)
at Test$.main(Test.scala:1)
at Test.main(Test.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at scala.reflect.internal.util.ScalaClassLoader$$anonfun$run$1.apply(ScalaClassLoader.scala:70)
at scala.reflect.internal.util.ScalaClassLoader$class.asContext(ScalaClassLoader.scala:31)
at scala.reflect.internal.util.ScalaClassLoader$URLClassLoader.asContext(ScalaClassLoader.scala:101)
at scala.reflect.internal.util.ScalaClassLoader$class.run(ScalaClassLoader.scala:70)
at scala.reflect.internal.util.ScalaClassLoader$URLClassLoader.run(ScalaClassLoader.scala:101)
at scala.tools.nsc.CommonRunner$class.run(ObjectRunner.scala:22)
at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:39)
at scala.tools.nsc.CommonRunner$class.runAndCatch(ObjectRunner.scala:29)
at scala.tools.nsc.ObjectRunner$.runAndCatch(ObjectRunner.scala:39)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:65)
at scala.tools.nsc.MainGenericRunner.run$1(MainGenericRunner.scala:87)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:98)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
What I tried and it didn't work:
Some threads on the internet mention that it might be caused by missing VC2008 runtime, so I made sure that I have it both for x64 and x86.
Extracting jansi.dll from scala/lib/jline-2.12.1.jar and putting it in my working directory (with "." included in java.library.path).
Starting with a fresh MSys2 home directory.
running bash --login -i from cmd.exe (same error when running scala)
trying 32-bit and 64-bit JREs
One more thing: the issue doesn't affect sbt; for example, running "sbt console" gives me a working Scala command line, albeit of version 2.10.4.

The problem is caused by the name clash between the scala shell script in scala/bin directory and scala.bat in the same directory. Msys2 runs the shell script, while cmd.exe runs the batch file. Apparently, the shell script is not suited for Msys2, which causes the error that I witnessed. Issuing cmd //c scala.bat from MSys2 results in a functional Scala command line.
It is also trivial to edit the scala shell script to support MSys2: https://gist.github.com/kirillkh/a9ba2e00ef2e901f13bf
I have opened a pull request with this change on the GitHub: https://github.com/scala/scala/pull/4674

native library for attach API not available in this JRE

I am attempting to build a new project with gradle, junit, and jmock. When I run my build, I get this stack trace:
com.heavyweightsoftware.daybook.ws.TypeCodeWsTest STANDARD_ERROR
java.lang.IllegalStateException: Native library for Attach API not available
in this JRE
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.ru
nTestClass(JUnitTestClassExecuter.java:80)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.ex
ecute(JUnitTestClassExecuter.java:49)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.p
rocessTestClass(JUnitTestClassProcessor.java:64)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.process
TestClass(SuiteTestClassProcessor.java:50)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(Con
textClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocat
ionHandler.invoke(ProxyDispatchAdapter.java:93)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestCl
ass(TestWorker.java:106)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(Messa
geHub.java:360)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
Caused by: java.lang.UnsatisfiedLinkError: no attach in java.library.path
... 14 more
Gradle Test Executor 1 finished executing tests.
com.heavyweightsoftware.daybook.ws.TypeCodeWsTest > testGetTypeCodes FAILED
java.lang.ExceptionInInitializerError
at com.heavyweightsoftware.daybook.ws.TypeCodeWsTest.testGetTypeCodes(Ty
peCodeWsTest.java:40)
Caused by:
java.lang.IllegalStateException: Native library for Attach API not avail
able in this JRE
at mockit.internal.startup.AgentLoader.getVirtualMachineImplementati
onFromEmbeddedOnes(AgentLoader.java:78)
at mockit.internal.startup.AgentLoader.loadAgent(AgentLoader.java:46
)
at mockit.internal.startup.Startup.verifyInitialization(Startup.java
:172)
at mockit.Invocations.<clinit>(Invocations.java:26)
... 1 more
Caused by:
java.lang.NoClassDefFoundError: Could not initialize class sun.tools
.attach.WindowsVirtualMachine
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unk
nown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at mockit.internal.startup.AgentLoader.getVirtualMachineImplemen
tationFromEmbeddedOnes(AgentLoader.java:70)
... 4 more
So I looked and found these questions: JMockit ERROR - Native library for Attach API not available in this JRE and jmockit: Native library for Attach API not available in this JRE error
And I've made the changes in eclipse, but this error happens even when running outside of eclipse and so it's not the eclipse settings.
Here's the output of java -version from the command prompt:
C:\Users\thom\git\daybook\WebServices>java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
This is part of gradle build --info:
Executing task ':test' (up-to-date check took 0.193 secs) due to:
Value of input property 'candidateClassFiles' has changed for task ':test'
Starting process 'Gradle Test Executor 1'. Working directory: C:\Users\thom\git\
daybook\WebServices Command: C:\java\bin\java.exe -Djava.security.manager=jarjar
.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=wind
ows-1252 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp C:\Users\th
om\.gradle\caches\2.4\workerMain\gradle-worker.jar jarjar.org.gradle.process.int
ernal.launcher.GradleWorkerMain 'Gradle Test Executor 1'
Successfully started process 'Gradle Test Executor 1'
Gradle Test Executor 1 started executing tests.
Which tells me it's running java from c:\java\bin which is the right install. I looked and this directer has javac in it, which I think confirms that it's a JDK and not a JRE.
Any input, oh wise above wise?

I added c:\java\jre\bin to my path and the build started working again.

Jruby Heap Dump Failure

I am running an APP using Jruby and Puma. We have an issue with a potential memory leak and I would like to generate a heap dump so that I can debug. My local environment is running Linux Mint 17.
I have run the following:
jmap -histo:live 6450
and this resulted in :
6450: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding
I've also tried this:
jmap -dump:live,format=b,file=heap.bin 6450
result
6450: Unable to open socket file: target process not responding or HotSpot VM not loaded
As the propmt suggested I tried running with the -F flag:
jmap -F -dump:live,format=b,file=heap.bin 6450
Attaching to process ID 6450, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.45-b02
Dumping heap to heap.bin ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda$10x0000000100393428
at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance(HeapHprofBinWriter.java:803)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(AbstractHeapGraphWriter.java:95)
at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(ObjectHeap.java:353)
at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:433)
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more`
Does anyone have any suggestions as to how to get around these errors and generate a heap dump ? I have tried using jvisualvm and Eclipse Memory Analyzer to generate a heap dump as well, and I run into the same issue.

This looks like a JVM bug in jdk 1.8_45 see this link for more info
https://bugs.openjdk.java.net/browse/JDK-8065318

JProfiler UnsatisfiedLinkError when starting

I just downloaded and installed a trial JProfiler version from jprofiler_linux_7_0_1.sh. The strange fact is that there's no prompt for inputting license information in the installing process. But everything seems to be fine, until I try to run the profiler:
# sh ./bin/jprofiler -c
(The -c is to run jprofiler in console. I have read somewhere on Internet, but not sure that's true. Anyway, the result is still the same.)
Here's the results I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/jdk1.6.0_26/jre/lib/amd64/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
at java.lang.Runtime.load0(Runtime.java:770)
at java.lang.System.load(System.java:1003)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
at java.awt.Component.<clinit>(Component.java:566)
at com.install4j.runtime.splashscreen.JavaSplashController.show(Unknown Source)
at com.install4j.runtime.launcher.SplashEngine.showSplashScreen(Unknown Source)
at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
I have come to /opt/jdk1.6.0_26/jre/lib/amd64/xawt; it does have libmawt.so, but no libXext.so.6. I tried to uninstall jprofiler and install it again, but the same error occurs.
Does anyone have a clue what's happening here?

You cannot run the JProfiler GUI in console mode. The argument -c is only for running the installer in console mode.
To set up profiling on a headless machine, run
bin/jpintegrate
To control a profiled process that does not have a JProfiler GUI attached ("offline profiling") run
bin/jpcontroller

Check that you have got libxtst in your operation system. To install it, you can do something like this: "sudo apt-get install libxtst6:
PS: You could also try to use YourKit Java Profiler with evaluation license.