Looks like the position of Java heap (0xdfff8000) interferes with ASan shadow memory mappings. See memory layout in projects/compiler-rt/lib/asan/asan_mapping.h.
__asan_region_is_poisoned arguments seem to be a red herring - it's possible that debug info is incorrect. On Fri, Jun 5, 2015 at 5:53 AM, Dmitriy - <[email protected]> wrote: > I tried to debug it with gdb. > Result: > in this line: > > memset( reserved_base, 0, lspace_size ); > > I want to fill reserved_base. > reserved_base = 0xdfff8000 > lspace_size = 4194304 (400000 in hex) > > my process memory map: > ... > 0008fff7000 1310692K ----- [ anon ] > 000dfff0000 32K ----- [ anon ] > 000dfff8000 4096K rw--- [ anon ] > 000e03f8000 520224K ----- [ anon ] > 00100000000 2145648604K ----- [ anon ] > 2008fff7000 15032123396K rw--- [ anon ] > ... > > java heap start this -> 000dfff8000 4096K rw--- [ anon ] > java heap size = 4194304 bytes > All ok. > I simply want to fill it with zero. > > next my step by step gdb ouput: > > __asan_memset (block=0xdfff8000, c=0, size=4194304) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:431 > 431 ASAN_MEMSET_IMPL(nullptr, block, c, size); > (gdb) step > QuickCheckForUnpoisonedRegion (size=4194304, beg=3758063616) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:34 > 34 if (size == 0) return true; > (gdb) step > __asan_memset (block=0xdfff8000, c=0, size=4194304) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:431 > 431 ASAN_MEMSET_IMPL(nullptr, block, c, size); > (gdb) step > QuickCheckForUnpoisonedRegion (size=4194304, beg=3758063616) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:35 > 35 if (size <= 32) > (gdb) p size > $5 = 4194304 > (gdb) step > __asan_memset (block=0xdfff8000, c=0, size=4194304) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:431 > 431 ASAN_MEMSET_IMPL(nullptr, block, c, size); > (gdb) step > __asan_region_is_poisoned (beg=4194304, size=4194304) > at > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_poisoning.cc:186 > 186 if (!size) return 0; > (gdb) p size > $6 = 4194304 > > My question is - why __asan_region_is_poisoned be called with beg = > 4194304, why not beg=0x000dfff8000? > > > On Thursday, May 28, 2015 at 1:15:34 AM UTC+6, Yuri Gribov wrote: > >> On Wed, May 27, 2015 at 1:52 PM, Dmitriy - <[email protected]> wrote: >> >>> Hello all. >>> I try using ASan for debug jvm. >>> >>> All .so library in jvm instrumented with ASan. >>> But, I have some error here: >>> >>> LD_PRELOAD=/usr/lib/libclang_rt.asan-x86_64.so >>> LD_LIBRARY_PATH=./dist/jdk_7/debug/open/jdk/jre/lib/amd64/drlvm/ >>> ./dist/jdk_7/debug/open/jdk/jre/bin/java -XX:-UseG1GC -version >>> ================================================================= >>> ==24418==ERROR: AddressSanitizer: unknown-crash on address >>> 0x0000dfff8000 at pc 0x7f6c2e9ab3d9 bp 0x7f6c28773960 sp 0x7f6c28773110 >>> WRITE of size 4194304 at 0x0000dfff8000 thread T1 >>> #0 0x7f6c2e9ab3d8 in __asan_memset >>> /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:431 >>> #1 0x7f6c12fbd7d5 in lspace_initialize(GC*, void*, unsigned long) >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/los/lspace.cpp:44:5 >>> #2 0x7f6c12f9fc8c in gc_los_initialize(GC_Gen*, void*, unsigned >>> long) >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/gen/gen.cpp:476:24 >>> #3 0x7f6c12f9f63f in gc_gen_initialize(GC_Gen*, unsigned long, >>> unsigned long) >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/gen/gen.cpp:313:5 >>> #4 0x7f6c12f848eb in gc_init >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/common/gc_for_vm.cpp:104:5 >>> #5 0x7f6c29cc9623 in vm_init1(JavaVM_Internal*, JavaVMInitArgs*, >>> JNIEnv_External**) >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/init/vm_init.cpp:796:14 >>> #6 0x7f6c29b27f2c in JNI_CreateJavaVM >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/jni/jni.cpp:436:19 >>> #7 0x7f6c29b286b4 in CVMI_CreateJavaVM >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/jni/jni.cpp:526:12 >>> #8 0x7f6c2abd0634 in JNI_CreateJavaVM >>> /home/dbezheckov/waratek/harmony-custom/drlvm/vm/openjdk/src/openjdk.cpp:90:12 >>> #9 0x7f6c2e6fdb47 >>> >>> (/home/dbezheckov/waratek/harmony-custom/dist/jdk_7/debug/open/jdk/jre/bin/../lib/amd64/jli/libjli.so+0x2b47) >>> #10 0x7f6c2df1c181 in start_thread >>> /build/buildd/eglibc-2.19/nptl/pthread_create.c:312 >>> #11 0x7f6c2e43047c in clone >>> /build/buildd/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >>> >> >> I don't think this rings any bells. Do you could try to analyze backtrace >> with gdb? You could use sleep_before_dying to attach to process on error. >> >> -Y >> > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Alexey Samsonov, Mountain View, CA -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
