Running hotspot with valgrind to detect memory leak?

Mon May 21 13:07:30 PDT 2007

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

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