Running hotspot with valgrind to detect memory leak?

Neo Jia neojia at gmail.com
Mon May 21 12:32:07 PDT 2007 

On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> Hi Neo,
>
>     Thanks for your analysis of the logs. Unfortunately I do not have a
> means of publishing the Valgrind results in a web accessible manner. I
> am sending you the results and would really appreciate if you could
> publish the same in the location you published your results earlier. I
> will check with HotSpot folks if there is any other means of publishing
> these logs from Sun.

Sandeep,

Thanks for your log file. I just put it on my Sun Workstation :), you
may access it at
http://neoworld.unl.edu/~cjia/openJDK/valgrind_hotspot_memory/valgrind_java.log.

BTW, I assume that this test case will not fail if you run it without
valgrind, right?

Thanks,
Neo

>
> Thanks,
> Sandeep
>
> Neo Jia wrote:
> > 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!

More information about the hotspot-dev mailing list