> I update the code (github): https://github.com/avazquezdev/TestValgrindJava
> valgrind-3.10.1 > Kubuntu 15.04 (64bits) > I created two files with the outputs whether or no memory leak. > https://github.com/avazquezdev/TestValgrindJava/tree/master/ErrorInfo > When I allocate memory valgrind show the next: > https://github.com/avazquezdev/TestValgrindJava/blob/master/ErrorInfo/Example1.txt > In this text I see nothing to indicate that my library allocates/free memory. Looking at https://raw.githubusercontent.com/avazquezdev/TestValgrindJava/master/ErrorInfo/Leak.txt I see signs of a large disconnect or misunderstanding between valgrind and the installed java. --10539-- Reading syms from /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java --10539-- Considering /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java .. --10539-- .. CRC mismatch (computed 47030d71 wanted 31641b1e) --10539-- object doesn't have a symbol table Not finding the symbol table for .../jre/bin/java could mean that valgrind will miss the connection to some allocators and deallocators, which will cripple much of memcheck's machinery. Determine why there is no symbol table; the "CRC mismatch" indicates that the symbol table probably was stripped. Do not do that. The next message --10539-- Reading syms from /lib/x86_64-linux-gnu/libc-2.21.so --10539-- Considering /lib/x86_64-linux-gnu/libc-2.21.so .. --10539-- .. CRC mismatch (computed 9362f137 wanted 040e4cfb) --10539-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.21.so .. --10539-- .. CRC is valid indicates that /lib/x86_64-linux-gnu/libc-2.21.so also has no symbol table, but that a substitute was found in /usr/lib/debug. Perhaps you could install the corresponding jvm/java-7-openjdk-amd64/jre/bin/java (with symbol table) also beneath /usr/lib/debug ? In general, if valgrind does not find the symbols, then that is bad. Don't strip the symbol table; else install the un-stripped version beneath /usr/lib/debug. The first complaint regarding executed code: ==10539== Thread 2: ==10539== Conditional jump or move depends on uninitialised value(s) ==10539== at 0x60F6178: Arena::Arena() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x677BCD4: Thread::Thread() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x6782474: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so) ==10539== by 0x561B6A9: start_thread (pthread_create.c:333) ==10539== Uninitialised value was created by a heap allocation ==10539== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==10539== by 0x6642F89: os::malloc(unsigned long, unsigned short, unsigned char*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x60F621F: Arena::operator new(unsigned long, unsigned short) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x677BCC4: Thread::Thread() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x6782474: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so) ==10539== by 0x561B6A9: start_thread (pthread_create.c:333) might be correct and valid. Or, it might be a cascade from memcheck not being connected to the java equivalent of calloc(), which initializes to zero. The next kind of complaint ==10539== Invalid write of size 4 ==10539== at 0x855E445: ??? ==10539== by 0x854E4E6: ??? ==10539== by 0x644AAD3: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x644A547: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x6409286: instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x6409318: instanceKlass::call_class_initializer(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x64094F4: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x64099A0: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x6409657: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x64099A0: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x67831A5: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== Address 0x4158630 is on thread 2's stack ==10539== 4096 bytes below stack pointer indicates that memcheck is not in sync with the java environment. Either memcheck has not seen (or not recognized) a "change the stack pointer" event, or java has implicit conventions about threads, stacks, and thread-local storage that memcheck does not know or does not understand. The leak check summary ==10539== HEAP SUMMARY: ==10539== in use at exit: 22,902,921 bytes in 1,235 blocks ==10539== total heap usage: 22,721 allocs, 21,486 frees, 44,322,524 bytes allocated ==10539== ==10539== Searching for pointers to 1,235 not-freed blocks ==10539== Checked 3,488,897,480 bytes indicates that memcheck believes the allocation arenas are around 3.3GB big. That's a lot, especially for your tiny example program. That's another worrisome sign of a disconnect between memcheck and java. The largest leaks ==10539== 5,242,880 bytes in 5 blocks are still reachable in loss record 779 of 779 ==10539== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==10539== by 0x6642F89: os::malloc(unsigned long, unsigned short, unsigned char*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x66A1580: ParCompactionManager::initialize(ParMarkBitMap*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x66A8899: PSParallelCompact::post_initialize() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x666AD04: ParallelScavengeHeap::post_initialize() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x679EC1B: universe_post_init() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x63FD939: init_globals() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x67825DE: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==10539== by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so) ==10539== by 0x561B6A9: start_thread (pthread_create.c:333) hint that memcheck might not understand the conventions of java GarbageCollector. In summary: fix the symbol table problems first. ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
