Running hotspot with valgrind to detect memory leak?
Neo Jia
neojia at gmail.com
Mon May 21 15:27:53 PDT 2007
On 5/21/07, Sandeep Konchady <Sandeep.Konchady at sun.com> wrote:
> Neo,
>
> Thanks for publishing the log file. Yes, the MemoryMonitor demo does
> work fine if I run it without Valgrind. Somehow the combination of the
> two seems to crash the VM.
Sandeep,
I tried the valgrind (latest version 3.2.3) with the openJDK (latest
svn checkout) on my Intel IA32 machine running Fedora Core 3. Valgrind
crashes even before the application runs :(. I have to wait for Fedora
7 this Friday.
Are you using the latest version of openJDK from svn? Can you run
valgrind with "-v"?
Thanks,
Neo
>
> - Sandeep
>
> Neo Jia wrote:
> > 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