Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Valgrind and Java

Tags:

I want to use Valgrind 3.7.0 to find memory leaks in my Java native code. I'm using jdk1.6.0._29.

To do that, I have to set the --trace-children=yes flag. Setting that flag, I no longer can run valgrind on any java application, even a command like:

valgrind --trace-children=yes --smc-check=all java -version 

will get the error message:

   Error occurred during initialization of VM    Unknown x64 processor: SSE2 not supported 

I've seen this link: https://bugs.kde.org/show_bug.cgi?id=249943, but it was not useful.

Running the program without Valgrind or without the --trace-children flag is fine.

Does anyone has any idea on what I can do?

like image 549
RezaPlusPlus Avatar asked Feb 09 '12 18:02

RezaPlusPlus


People also ask

Can Valgrind be used with Java?

Apart from this, in theory Valgrind can run any Java program just fine, even those that use JNI and are partially implemented in other languages like C and C++.

What is Java memory leak?

In general, a Java memory leak happens when an application unintentionally (due to logical errors in code) holds on to object references that are no longer required. These unintentional object references prevent the built-in Java garbage collection mechanism from freeing up the memory consumed by these objects.

Is Valgrind ever wrong?

Yes, there are false positives with Valgrind, that's why it has suppression files for particular glibc and gcc versions, for example. The false positives may arise if you are using older valgrind with newer gcc and glibc, i.e., valgrind 3.3 with glibc 2.9.


1 Answers

You must disable JIT to run the JVM under valgrind, like so:

valgrind java -Djava.compiler=NONE ... 

Also, if you end up using generated suppressions (and you most likely will!), there can be a problem with the depth of the call stacks in the generated suppressions, which is more likely to occur when running under the JVM.

In recent versions of valgrind, generated suppressions can contain deeper call stacks than can be processed by valgrind/memcheck itself. The symptom of this problem is that valgrind terminates unexpectedly with the message "too many callers in stack trace".

This problem is easily fixed: before building valgrind, edit the file coregrind/m_errormgr.c and change the hard-coded value in the #define to a larger value (I use 99):

 /* Max number of callers for context in a suppression. */   #define VG_MAX_SUPP_CALLERS  99 

Then build and install valgrind as per the docs.

like image 99
BillT Avatar answered Sep 22 '22 20:09

BillT