Running hotspot with valgrind to detect memory leak?

[Neo Jia]

On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>
>  Neo,
>
>      I have not done any extensive work on Valgrind, so I am not sure how
> best to interpret the logs. That said the one interesting thing is that
> there is a leak listed in nmethod call just before it crashed.

Sandeep,

Thank you for your quick responds!

I think that leak is not the root cause of this problem. See my comments below.

However the
> overall leak was not that significant. Let me know if you want to take a
> peek at the complete log.

Yes, I would like to take a look at the complete log. Due to the
mailing list limitation, posting a link should be fine.

>
>  ==00:00:17:26.750 6946== 3,587,249 bytes in 2,672 blocks are still
> reachable in loss record 264 of 264

Those "loss record" are still "reachable", which means those memory
still can be claimed by program (probably GC if it is on the GC-heap).

>  ==00:00:17:26.750 6946==    at 0x4021620: malloc (vg_replace_malloc.c:149)
>  ==00:00:17:26.750 6946==    by 0x6328E96: os::malloc(unsigned) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x61A7FD8:
> CodeBlob::set_oop_maps(OopMapSet*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x61A87AB: CodeBlob::CodeBlob(char const*,
> CodeBuffer*, int, int, int, int, OopMapSet*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.750 6946==    by 0x631E154:
> nmethod::nmethod(methodOopDesc*, int, int, int,
> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*,
> int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
> AbstractCompiler*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x631F115:
> nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*,
> int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*,
> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x617D80E:
> ciEnv::register_method(ciMethod*, int, CodeOffsets*, int,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61021EA: Compilation::compile_method() (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61023AC:
> Compilation::Compilation(AbstractCompiler*, ciEnv*,
> ciMethod*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61025C7:
> Compiler::compile_method(ciEnv*, ciMethod*, int) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61BB195:
> CompileBroker::invoke_compiler_on_method(CompileTask*) (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==    by 0x61BC246:
> CompileBroker::compiler_thread_loop() (in
> /home/konchady/Projects/OpenJKD/openjdk/control/build/linux-i586/lib/i386/client/libjvm.so)
>  ==00:00:17:26.751 6946==
>  ==00:00:17:26.752 6946== LEAK SUMMARY:
>  ==00:00:17:26.752 6946==    definitely lost: 15,125 bytes in 168 blocks.

Actually, I am pretty interested in those "definitely lost". Will that
be a potential bug or will this show that Valgrind cannot detect
memory leak for a VM, which has its own GC?

Thanks,
Neo

>  ==00:00:17:26.752 6946==    indirectly lost: 83,108 bytes in 2,814 blocks.
>  ==00:00:17:26.752 6946==      possibly lost: 15,521 bytes in 33 blocks.
>  ==00:00:17:26.752 6946==    still reachable: 4,289,428 bytes in 5,384
> blocks.
>  ==00:00:17:26.752 6946==         suppressed: 0 bytes in 0 blocks.
>
>
>  Thanks,
>  Sandeep
>
>  Neo Jia wrote:
> On 5/20/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
>
> Hi,
>
>      Extending what Neo Jia ran on JVM, I tested OpenJDK VM with Valgrind
>  using MemoryMonitor demo. To my surprise I got a HotSpot crash in
>  nmethod.cpp. I am attaching hs_err log file to this email and can give
>  the Valgrind log if needed. Also I was unable to find similar report on
>  SDN bug database.
>
>  #  Internal Error (nmethod.cpp:1822), pid=6946, tid=80788368
>  #  Error: guarantee(cont_offset != 0,"unhandled implicit exception in
>  compiled code")
>
>  Sandeep,
>
>  Is there anything interesting in the valgrind log file?
>
>  Thanks,
>  Neo
>
>
>
>  Thanks,
>  Sandeep
>
>  Neo Jia wrote:
>  > hi,
>  >
>  > For fun, I just ran the hotspot vm with valgrind memory checking. To
>  > my surprise, valgrind has identified several "memory leak" inside vm.
>  > Although there might be some false positive, I still would like to dig
>  > a little bit.
>  >
>  > For your reference, you may get the log file from the following link
>  > since it is too huge to send through a mailing list. This tiny log
>  > file is generated by running helloworld.java.
>  >
>  >
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666
>  >
>  >
> http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_helloworld/valgrind_java_helloworld.30666.1
>  >
>  >
>  > Thanks,
>  > Neo
>
>
>
>
>
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!