2

I'm using JMagick and have a simple Java class that loops over all images in a directory (and its sub directories), converting images into grayscale images.

After my application runs for a while the JVM crashes. I believe the error message in the log is possibly suggesting that there were memory issues:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j magick.MagickImage.writeImage(Lmagick/ImageInfo;)Z+0 j com.example.ImageGenerator.generateAlternativeImages(Ljava/io/File;Z)V+91 j com.example.ImageGenerator.main([Ljava/lang/String;)V+58 v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread ) 0x0ab0c800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1532, stack(0x0aec0000,0x0af10000)] 0x0ab0ac00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7304, stack(0x0ae70000,0x0aec0000)] 0x0aafe000 JavaThread "JDWP Command Reader" daemon [_thread_in_native, id=6836, stack(0x0ae20000,0x0ae70000)] 0x0aafc800 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=7248, stack(0x0add0000,0x0ae20000)] 0x0aafa400 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_blocked, id=6252, stack(0x0ad80000,0x0add0000)] 0x0aaee800 JavaThread "Attach Listener" daemon [_thread_blocked, id=2020, stack(0x0aca0000,0x0acf0000)] 0x0aaed400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7492, stack(0x0ac50000,0x0aca0000)] 0x0aada400 JavaThread "Finalizer" daemon [_thread_blocked, id=5400, stack(0x0ac00000,0x0ac50000)]
0x0aad8c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=5772, stack(0x0abb0000,0x0ac00000)] =>0x002b8000 JavaThread "main" [_thread_in_native, id=7020, stack(0x008c0000,0x00910000)]

Other Threads: 0x0aad5400 VMThread [stack: 0x0ab60000,0x0abb0000] [id=7720] 0x0ab0f000 WatcherThread [stack: 0x0af10000,0x0af60000] [id=6432]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap def new generation total 960K, used 793K [0x029c0000, 0x02ac0000, 0x02ea0000) eden space 896K, 88% used [0x029c0000, 0x02a865f0, 0x02aa0000) from space 64K, 0% used [0x02aa0000, 0x02aa0000, 0x02ab0000) to space 64K, 0% used [0x02ab0000, 0x02ab0000, 0x02ac0000) tenured generation total 4096K, used 0K [0x02ea0000, 0x032a0000, 0x069c0000) the space 4096K, 0% used [0x02ea0000, 0x02ea0000, 0x02ea0200, 0x032a0000) compacting perm gen total 12288K, used 2219K [0x069c0000, 0x075c0000, 0x0a9c0000) the space 12288K, 18% used [0x069c0000, 0x06bead18, 0x06beae00, 0x075c0000) No shared spaces configured.

I've tried adding -Xmx options but figure this might not be the solution. Any suggestions?

Thanks in advance.

Andrea
  • 11,801
  • 17
  • 65
  • 72
Ed .
  • 6,373
  • 8
  • 62
  • 82
  • Did you try to monitor your application using jconsole or visualvm and notice anything unusual when the crash occurs? – Scorpion Sep 09 '11 at 18:08

3 Answers3

4

Your JVM crashed, -Xmx will not help. Can you try running with -Xint and see if you can reproduce the problem? This will tell the JVM to run without Hotspot, which means no dynamic compilation optimizations. Which version of the JVM are you running with? If you can't reproduce the problem with -Xint, and you're using the latest JVM, you can try excluding only magick.MagickImage.writeImage from being compiled.

To exclude, create a file in the applications working directory called:

.hotspot_compiler

and add the line :

exclude magick/MagickImage writeImage
Amir Afghani
  • 37,814
  • 16
  • 84
  • 124
  • Thanks - I added -Xint and the application runs with no problems. Slightly confusing now however is that it is also working without it...maybe setting -Xint once has an effect on compiled classes..? Or my computer is just happier this week. – Ed . Sep 12 '11 at 08:16
  • Dynamic compilation errors are notoriously difficult, and can be intermittent. You should know that by setting -Xint you are turning off a lot of runtime optimizations. My second recommendation of selectively excluding the offensive method is more appropriate as a final solution. – Amir Afghani Sep 12 '11 at 17:11
2

If you suspect it to be a memory issue then run the application with the option -XX:+HeapDumpOnOutOfMemoryError. This will create a heap dump if the application crashes due to OOME. You can then analyze the heap dump using tools like jhat or eclipse mat.

You can also generate the heap dump of a running application using jmap and see the memory consumption using the tools suggested above to be sure of your suspicion.

Scorpion
  • 3,938
  • 24
  • 37
0

I found that you need to destroy every image copy you create. Otherwise you create a memory leak. It is using JNI and I think there are mallocs which need to be freed.

Marcel Pater
  • 164
  • 10