double free or corruption

Deneau, Tom tom.deneau at amd.com
Thu Jul 24 20:24:09 UTC 2014


Using MALLOC_CHECK_ = 1 or 2 resulted in the heap being at a low address and uncovered a bug in the HSAILAssembler in the way we output HSAIL for constant addresses, but unfortunately with that bug fixed and MALLOC_CHECK_ on, I don't see any of the original failures.

I tried calling mcheck(0) in the debugger at startup time but that resulted in immediate errors (hopefully not significant) reading " memory clobbered before allocated block" in places like os::current_stack_size.  Maybe this is similar to the complaints of valgrind?

#3  0x00007ffff786e5de in __GI___libc_fatal (message=0x7ffff79831d0 "memory clobbered before allocated block\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:210
#4  0x00007ffff78802d5 in mabort (status=<optimized out>) at mcheck.c:364
#5  0x00007ffff788079e in checkhdr (hdr=0x7fffcc000890) at mcheck.c:115
#6  checkhdr (hdr=0x7fffcc000890) at mcheck.c:181
#7  freehook (ptr=0x7fffcc0008c0, caller=0x7ffff73e28ad <__pthread_attr_destroy+13>) at mcheck.c:188
#8  0x00007ffff73e28ad in __pthread_attr_destroy (attr=<optimized out>) at pthread_attr_destroy.c:41
#9  0x00007ffff6918b47 in current_stack_region (bottom=0x7fffdbefdaf0, size=0x7fffdbefdaf8) at /home/user1/SumatraDemos/graal/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:731
#10 0x00007ffff6918c09 in os::current_stack_size () at /home/user1/SumatraDemos/graal/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:749
#11 0x00007ffff6a68ba9 in Thread::record_stack_base_and_size (this=0x7ffff003b000) at /home/user1/SumatraDemos/graal/src/share/vm/runtime/thread.cpp:322

-- Tom


-----Original Message-----
From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com] 
Sent: Tuesday, July 22, 2014 1:15 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: double free or corruption

In the past valgrind hasn't worked well with hotspot because of various tricks it plays with storage management but the error below doesn't look unreasonable.  At a guess I'd say this code is pointing at line 217 in icBuffer.cpp where the CompiledICHolder is being freed.

  while (holder != NULL) {
    CompiledICHolder* next = holder->next();
    delete holder;

I don't think any particularly clever tricks are being played here so I don't know why it would be reporting a problem.  It could just be valgrind getting confused.

Have you tried running with the debug options of GNU malloc?  Setting MALLOC_CHECK_=1 in your environment will enable some debug code which reports the errors it detects.  The value 2 causes it to abort immediately instead It can't detect everything valgrind does but double frees and other basic errors are caught.

tom

On Jul 22, 2014, at 11:03 AM, Deneau, Tom <tom.deneau at amd.com> wrote:

> I tried valgrind on a fairly simple mx unittest run for which the list of unittests was basically 32 copies of com.oracle.graal.jtt.bytecode.BC_aload_1
> com.oracle.graal.jtt.bytecode.BC_aload_0
> com.oracle.graal.jtt.bytecode.BC_aload_3
> com.oracle.graal.jtt.bytecode.BC_aload_2
> 
> I get some valgrind errors of the following form.   Is this expected?
> I seem to only see this on the product build, not fastdebug or debug.
> 
> ==11432==  Address 0x206c0ed8 is 8 bytes inside a block of size 24 free'd
> ==11432==    at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==11432==    by 0x61E5810: InlineCacheBuffer::update_inline_caches() (allocation.inline.hpp:83)
> ==11432==    by 0x64EFF9F: SafepointSynchronize::do_cleanup_tasks() (safepoint.cpp:527)
> ==11432==    by 0x64F0914: SafepointSynchronize::begin() (safepoint.cpp:403)
> ==11432==    by 0x65FCFB9: VMThread::loop() (vmThread.cpp:496)
> ==11432==    by 0x65FD411: VMThread::run() (vmThread.cpp:274)
> ==11432==    by 0x6459EC1: java_start(Thread*) (os_linux.cpp:860)
> 
> 
> -- Tom
> 
> 
> -----Original Message-----
> From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
> Sent: Tuesday, July 22, 2014 11:33 AM
> To: graal-dev at openjdk.java.net
> Subject: double free or corruption
> 
> What is the best technique to debug an error like the following (after having made some hotspot changes)...
> 
> -- Tom
> 
> *** Error in `/home/user1/SumatraDemos/graal/jdk1.8.0-internal/product/bin/java': double free or corruption (!prev): 0x00002b80e8517a30 ***
> 



More information about the graal-dev mailing list