Hi Konstantin,

Another case for heap reuse.

int main() {
  char *x = new char[20];
  delete[] x;
  return x[0];
}

ASAN:SIGSEGV
=================================================================
==6524==ERROR: AddressSanitizer: SEGV on unknown address
0x003180001dfc (pc 0x0000004c4188 bp 0x03fffffff4c0 sp 0x03fffffff490
T0)
    #0 0x4c4187  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c4187)
    #1 0x3ffb7b90c93  (/lib64/libc.so.6+0x20c93)
    #2 0x41b7ab  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x41b7ab)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c4187)
==6524==ABORTING

Snip from assembly

(--snip--)
.LBB0_2:                                // %delete.end
        ldur    x8, [x29, #-16]
        lsr     x9, x8, #3
        orr     x9, x9, #0x1000000000
        ldrb     w10, [x9]
(--snip--)

I manually changed it to

(--snip--)
.LBB0_2:                                // %delete.end
        ldur    x8, [x29, #-16]
        lsr     x9, x8, #3
        orr     x9, x9, #0x8000000000 <== shadow offset
        ldrb     w10, [x9]
(--snip--)

Now I am able to get ASAN report.

[root@SQA-Overdrive02-010236011075 build-asan-64bit]# ./a.out
=================================================================
==6548==ERROR: AddressSanitizer: heap-use-after-free on address
0x010c0000efe0 at pc 0x0000004c41c8 bp 0x03fffffff470 sp
0x03fffffff488
READ of size 1 at 0x010c0000efe0 thread T0
    #0 0x4c41c7  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c41c7)
    #1 0x3ffb7b90c93  (/lib64/libc.so.6+0x20c93)
    #2 0x41b7ab  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x41b7ab)

0x010c0000efe0 is located 0 bytes inside of 20-byte region
[0x010c0000efe0,0x010c0000eff4)
freed by thread T0 here:
    #0 0x4c3b63  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c3b63)
    #1 0x4c417b  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c417b)
    #2 0x3ffb7b90c93  (/lib64/libc.so.6+0x20c93)
    #3 0x41b7ab  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x41b7ab)


Looks like shadow offset is still set as 1<<36.

This is my patch

[root@SQA-Overdrive02-010236011075 compiler-rt]# git diff
diff --git a/cmake/config-ix.cmake b/cmake/config-ix.cmake
index 1207f4c..71e0646 100644
--- a/cmake/config-ix.cmake
+++ b/cmake/config-ix.cmake
@@ -222,7 +222,7 @@ endfunction()
 filter_available_targets(SANITIZER_COMMON_SUPPORTED_ARCH
   x86_64 i386 i686 powerpc64 powerpc64le arm aarch64 mips mips64 mipsel mips64e
 filter_available_targets(ASAN_SUPPORTED_ARCH
-  x86_64 i386 i686 powerpc64 powerpc64le arm mips mipsel mips64 mips64el)
+  x86_64 i386 i686 powerpc64 powerpc64le arm aarch64 mips mipsel mips64 mips64e
 filter_available_targets(DFSAN_SUPPORTED_ARCH x86_64 mips64 mips64el)
 filter_available_targets(LSAN_SUPPORTED_ARCH x86_64 mips64 mips64el)
 # LSan common files should be available on all architectures supported
diff --git a/lib/asan/asan_allocator.h b/lib/asan/asan_allocator.h
index 3208d1f..b46d4d2 100644
--- a/lib/asan/asan_allocator.h
+++ b/lib/asan/asan_allocator.h
@@ -115,6 +115,9 @@ struct AsanMapUnmapCallback {
 # if defined(__powerpc64__)
 const uptr kAllocatorSpace =  0xa0000000000ULL;
 const uptr kAllocatorSize  =  0x20000000000ULL;  // 2T.
+# elif  defined(__aarch64__)
+const uptr kAllocatorSpace =  0x10000000000ULL;
+const uptr kAllocatorSize  =  0x10000000000ULL;  // 2T.
 # else
 const uptr kAllocatorSpace = 0x600000000000ULL;
 const uptr kAllocatorSize  =  0x40000000000ULL;  // 4T.
diff --git a/lib/asan/asan_mapping.h b/lib/asan/asan_mapping.h
index 5cb011d..87f99d8 100644
--- a/lib/asan/asan_mapping.h
+++ b/lib/asan/asan_mapping.h
@@ -101,7 +101,7 @@ static const u64 kDefaultShadowOffset32 = 1ULL << 29;  // 0x
 static const u64 kIosShadowOffset32 = 1ULL << 30;  // 0x40000000
 static const u64 kDefaultShadowOffset64 = 1ULL << 44;
 static const u64 kDefaultShort64bitShadowOffset = 0x7FFF8000;  // < 2G.
-static const u64 kAArch64_ShadowOffset64 = 1ULL << 36;
+static const u64 kAArch64_ShadowOffset64 = 1ULL << 39;
 static const u64 kMIPS32_ShadowOffset32 = 0x0aaa0000;
 static const u64 kMIPS64_ShadowOffset64 = 1ULL << 37;
 static const u64 kPPC64_ShadowOffset64 = 1ULL << 41;
diff --git a/lib/sanitizer_common/sanitizer_platform.h b/lib/sanitizer_common/sa
index fef5a5b..7dbd956 100644
--- a/lib/sanitizer_common/sanitizer_platform.h
+++ b/lib/sanitizer_common/sanitizer_platform.h
@@ -81,7 +81,7 @@
 // For such platforms build this code with -DSANITIZER_CAN_USE_ALLOCATOR64=0 or
 // change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here.
 #ifndef SANITIZER_CAN_USE_ALLOCATOR64
-# if defined(__aarch64__) || defined(__mips64)
+# if defined(__mips64)
 #  define SANITIZER_CAN_USE_ALLOCATOR64 0
 # else
 #  define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64)
@@ -93,7 +93,7 @@
 // e.g. on AArch64 it is most likely (1ULL << 39). Larger values will still wor
 // but will consume more memory for TwoLevelByteMap.
 #if defined(__aarch64__)
-# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 39)
+# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 42)
 #elif defined(__mips__)
 # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 40)
 #else

Am I missing something?

regards,
Venkat.

On 22 March 2015 at 20:33, Venkataramanan Kumar
<[email protected]> wrote:
> Hi,
>
>  Slightly changed the hello world test case to have a local variable
>
> #include <stdio.h>
> int main()
> {
>         int a[10]={0};
>         printf("Hello World\n");
>         return a[1];
> }
>
>
> With ASLR "on" I get
>
> ASAN:SIGSEGV
> =================================================================
> ==12464==ERROR: AddressSanitizer: SEGV on unknown address
> 0x007ff92af4ac (pc 0x0000004c41f4 bp 0x03ffc957a650 sp 0x03ffc957a560
> T0)
>     #0 0x4c41f3  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c41f3)
>     #1 0x3ffaacd0c93  (/lib64/libc.so.6+0x20c93)
>     #2 0x41b7ab  (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x41b7ab)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV
> (/root/work/vekumar/ASAN/build-asan-64bit/a.out+0x4c41f3)
>
>  setarch linux64 -R ./a.out
> Hello world
>
>
> On 22 March 2015 at 19:59, Venkataramanan Kumar
> <[email protected]> wrote:
>> Hi Konstantin,
>>
>> The machine I was working is down now. I am waiting for someone in
>> linaro lab to turn it on.
>>
>> Now I used another machine and with this one I am not getting segfault
>> for  the simple "hello world" test case.
>>
>> However ASAN tests continued to fail with same errors.
>>
>> An example
>> <stdin>:3:1: note: possible intended match here
>> ==4793==ERROR: AddressSanitizer: SEGV on unknown address
>> 0x007ffd9552d8 (pc 0x0000004c41e8 bp 0x03ffecaa9760 sp 0x03ffecaa96c0
>> T0)
>> ^
>>
>>
>> Below is the LLVM IR for the test case you gave.
>>
>> (------Snip----)
>> ; ModuleID = 'try.c'
>> target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
>> target triple = "aarch64-unknown-linux-gnu"
>>
>> @llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32,
>> void ()* } { i32 1, void ()* @asan.module_ctor }]
>>
>> ; Function Attrs: nounwind sanitize_address uwtable
>> define void @_Z3fooPl(i64* %x) #0 {
>> entry:
>>   %x.addr = alloca i64*, align 8
>>   store i64* %x, i64** %x.addr, align 8
>>   %0 = load i64*, i64** %x.addr, align 8
>>   %1 = ptrtoint i64* %0 to i64
>>   %2 = lshr i64 %1, 3
>>   %3 = or i64 %2, 68719476736
>>   %4 = inttoptr i64 %3 to i8*
>>   %5 = load i8, i8* %4
>>   %6 = icmp ne i8 %5, 0
>>   br i1 %6, label %7, label %8
>>
>> ; <label>:7                                       ; preds = %entry
>>   call void @__asan_report_store8(i64 %1)
>>   call void asm sideeffect "", ""()
>>   unreachable
>>
>> ; <label>:8                                       ; preds = %entry
>>   store i64 0, i64* %0, align 8
>>   ret void
>> }
>>
>> define internal void @asan.module_ctor() {
>>   call void @__asan_init_v5()
>>   ret void
>> }
>>
>> declare void @__asan_init_v5()
>>
>> declare void @__asan_report_load_n(i64, i64)
>>
>> declare void @__asan_loadN(i64, i64)
>>
>> declare void @__asan_report_load1(i64)
>>
>> declare void @__asan_load1(i64)
>>
>> declare void @__asan_report_load2(i64)
>>
>> declare void @__asan_load2(i64)
>>
>> declare void @__asan_report_load4(i64)
>>
>> declare void @__asan_load4(i64)
>>
>> declare void @__asan_report_load8(i64)
>>
>> declare void @__asan_load8(i64)
>>
>> declare void @__asan_report_load16(i64)
>>
>> declare void @__asan_load16(i64)
>>
>> declare void @__asan_report_store_n(i64, i64)
>>
>> declare void @__asan_storeN(i64, i64)
>>
>> declare void @__asan_report_store1(i64)
>>
>> declare void @__asan_store1(i64)
>>
>> declare void @__asan_report_store2(i64)
>>
>> declare void @__asan_store2(i64)
>>
>> declare void @__asan_report_store4(i64)
>>
>> declare void @__asan_store4(i64)
>>
>> declare void @__asan_report_store8(i64)
>>
>> declare void @__asan_store8(i64)
>>
>> declare void @__asan_report_store16(i64)
>>
>> declare void @__asan_store16(i64)
>>
>> declare void @__asan_report_exp_load_n(i64, i64, i32)
>>
>> declare void @__asan_exp_loadN(i64, i64, i32)
>>
>> declare void @__asan_report_exp_load1(i64, i32)
>>
>> declare void @__asan_exp_load1(i64, i32)
>>
>> declare void @__asan_report_exp_load2(i64, i32)
>>
>> declare void @__asan_exp_load2(i64, i32)
>>
>> declare void @__asan_report_exp_load4(i64, i32)
>>
>> declare void @__asan_exp_load4(i64, i32)
>>
>> declare void @__asan_report_exp_load8(i64, i32)
>>
>> declare void @__asan_exp_load8(i64, i32)
>>
>> declare void @__asan_report_exp_load16(i64, i32)
>>
>> declare void @__asan_exp_load16(i64, i32)
>>
>> declare void @__asan_report_exp_store_n(i64, i64, i32)
>>
>> declare void @__asan_exp_storeN(i64, i64, i32)
>>
>> declare void @__asan_report_exp_store1(i64, i32)
>>
>> declare void @__asan_exp_store1(i64, i32)
>>
>> declare void @__asan_report_exp_store2(i64, i32)
>>
>> declare void @__asan_exp_store2(i64, i32)
>>
>> declare void @__asan_report_exp_store4(i64, i32)
>>
>> declare void @__asan_exp_store4(i64, i32)
>>
>> declare void @__asan_report_exp_store8(i64, i32)
>>
>> declare void @__asan_exp_store8(i64, i32)
>>
>> declare void @__asan_report_exp_store16(i64, i32)
>>
>> declare void @__asan_exp_store16(i64, i32)
>>
>> declare i8* @__asan_memmove(i8*, i8*, i64)
>>
>> declare i8* @__asan_memcpy(i8*, i8*, i64)
>>
>> declare i8* @__asan_memset(i8*, i32, i64)
>>
>> declare void @__asan_handle_no_return()
>>
>> declare void @__sanitizer_ptr_cmp(i64, i64)
>>
>> declare void @__sanitizer_ptr_sub(i64, i64)
>>
>> declare void @__asan_before_dynamic_init(i64)
>>
>> declare void @__asan_after_dynamic_init()
>>
>> declare void @__asan_register_globals(i64, i64)
>>
>> declare void @__asan_unregister_globals(i64, i64)
>>
>> attributes #0 = { nounwind sanitize_address uwtable
>> "less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
>> "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
>> "no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
>> "target-cpu"="generic" "target-features"="+neon"
>> "unsafe-fp-math"="false" "use-soft-float"="false" }
>>
>> !llvm.ident = !{!0}
>>
>> !0 = !{!"clang version 3.7.0 (http://llvm.org/git/clang.git
>> f3f115679db522ca44f75e3dadf3cdef8679b928)
>> (http://llvm.org/git/llvm.git
>> 048ca17f6ea4386f608eea62ca716466bf9f674c)"}
>> (-----Snip------)
>>
>>  %2 = lshr i64 %1, 3
>>   %3 = or i64 %2, 68719476736
>>   %4 = inttoptr i64 %3 to i8*
>>
>> I am trying to understand  why  68719476736 (0x1000000000) has been
>> ored with stack here.
>>
>>
>> On 20 March 2015 at 21:27, Konstantin Serebryany
>> <[email protected]> wrote:
>>>>
>>>> OK. Let me start with this test case.
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int  main()
>>>> {
>>>>         printf("Hello World\n");
>>>>         return 0;
>>>> }
>>>>
>>>> /home/venkataramanan.kumar/
>>>> LLVM/TSAN_port/Build/./bin/clang
>>>> --driver-mode=g++ -fsanitize=address  test.c
>>>>
>>>> [venkataramanan.kumar@amd-01 ~]$ ./a.out
>>>> ASAN:SIGSEGV
>>>> =================================================================
>>>> ==25303==ERROR: AddressSanitizer: SEGV on unknown address
>>>> 0x007fff96387c (pc 0x0000004c1dfc bp 0x03fffcb1c460 sp 0x03fffcb1c3e0
>>>> T0)
>>>>     #0 0x4c1dfb  (/home/venkataramanan.kumar/a.out+0x4c1dfb)
>>>>     #1 0x3ff9c790c93  (/lib64/libc.so.6+0x20c93)
>>>>     #2 0x41b1f3  (/home/venkataramanan.kumar/a.out+0x41b1f3)
>>>>
>>>> AddressSanitizer can not provide additional info.
>>>> ==25303==ABORTING
>>>>
>>>>
>>>> Now I am running under gdb
>>>>
>>>> [venkataramanan.kumar@amd-01 ~]$ gdb ./a.out
>>>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-62.sa1.4
>>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later 
>>>> <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>>> and "show warranty" for details.
>>>> This GDB was configured as "aarch64-redhat-linux-gnu".
>>>> For bug reporting instructions, please see:
>>>> <http://www.gnu.org/software/gdb/bugs/>...
>>>> Reading symbols from /home/venkataramanan.kumar/a.out...done.
>>>> (gdb) r
>>>> Starting program: /home/venkataramanan.kumar/./a.out
>>>> [Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>> Hello World
>>>> [Inferior 1 (process 25306) exited normally]
>>>> Missing separate debuginfos, use: debuginfo-install
>>>> glibc-2.17-68.sa1.4.aarch64 libgcc-4.8.3-8.sa1.4.aarch64
>>>> libstdc++-4.8.3-8.sa1.4.aarch64
>>>>
>>>> It ran to completion.
>>>
>>>
>>> Interesting. So, w/ gdb the test passes, w/o gdb it fails.
>>> Try few things:
>>>
>>> Run w/o gdb but with ASLR off (is there ASLR on AArch64?). Use setarch for 
>>> that.
>>>
>>> Run w/ gdb but with ASLR on (disable-randomization off). If you get a
>>> crash with gdb, type 'dis' and send the result here.
>>>
>>> build the following code with -S and with '-S -o - -emit-llvm' and
>>> send the results:
>>> void foo(long *x)  { *x = 0; }
>>>
>>> --kcc
>>>
>>>
>>>>
>>>>
>>>> ASAN:SIGSEGV
>>>> ==============================
>>>> ===================================
>>>> ==6221==ERROR: AddressSanitizer: SEGV on unknown address
>>>> 0x007ffd1329f4 (pc 0x0000004c1e64 bp 0x03ffe8995090 sp 0x03ffe8994fa0
>>>> T0)
>>>>     #0 0x4c1e63 in main
>>>> /home/venkataramanan.kumar/LLVM/TSAN_port/compiler-rt/test/asan/TestCases/Linux/coverage-direct-large.cc:52
>>>>     #1 0x3ffb2730c93 in __libc_start_main (/lib64/libc.so.6+0x20c93)
>>>>
>>>> What this error mean?
>>>> Stack address 0x03ffe8994fa0 when I do 0x03ffe8994fa0 >> 0x3, I get
>>>> this address 0x007ffd1329f4,
>>>>
>>>> "address 0x007ffd1329f4 is illegal. Why this address is accessed?
>>>>
>>>> Between my cat /proc/self/maps look like that.
>>>>
>>>> venataramanan.kumar@amd-01 ~]$ cat /proc/self/maps
>>>> 00400000-00410000 r-xp 00000000 08:04 16890529
>>>>   /usr/bin/cat
>>>> 00410000-00420000 r--p 00000000 08:04 16890529
>>>>   /usr/bin/cat
>>>> 00420000-00430000 rw-p 00010000 08:04 16890529
>>>>   /usr/bin/cat
>>>> 07a30000-07a60000 rw-p 00000000 00:00 0                                  
>>>> [heap]
>>>> 3ff85ca0000-3ff8c540000 r--p 00000000 08:04 34089040
>>>>   /usr/lib/locale/locale-archive
>>>> 3ff8c540000-3ff8c6a0000 r-xp 00000000 08:04 33642757
>>>>   /usr/lib64/libc-2.17.so
>>>> 3ff8c6a0000-3ff8c6b0000 r--p 00150000 08:04 33642757
>>>>   /usr/lib64/libc-2.17.so
>>>> 3ff8c6b0000-3ff8c6c0000 rw-p 00160000 08:04 33642757
>>>>   /usr/lib64/libc-2.17.so
>>>> 3ff8c6d0000-3ff8c6e0000 r--p 00000000 00:00 0                            
>>>> [vvar]
>>>> 3ff8c6e0000-3ff8c6f0000 r-xp 00000000 00:00 0                            
>>>> [vdso]
>>>> 3ff8c6f0000-3ff8c710000 r-xp 00000000 08:04 33642750
>>>>   /usr/lib64/ld-2.17.so
>>>> 3ff8c710000-3ff8c720000 r--p 00010000 08:04 33642750
>>>>   /usr/lib64/ld-2.17.so
>>>> 3ff8c720000-3ff8c730000 rw-p 00020000 08:04 33642750
>>>>   /usr/lib64/ld-2.17.so
>>>> 3ffc0d80000-3ffc0db0000 rw-p 00000000 00:00 0                            
>>>> [stack]
>>>>
>>>>
>>>> regards,
>>>> Venkat.
>>>>
>>>>
>>>>
>>>>
>>>>>> regards,
>>>>>> Venkat,
>>>>>>
>>>>>>
>>>>>> On 26 January 2015 at 20:50,  <[email protected]> wrote:
>>>>>>>
>>>>>>> Comment #16 on issue 246 by [email protected]: Porting to a new target
>>>>>>> (AArch64)
>>>>>>> https://code.google.com/p/address-sanitizer/issues/detail?id=246
>>>>>>>
>>>>>>> FYI, following patch makes ASAN work fine on 42-bit AS, but will break 
>>>>>>> the
>>>>>>> 39-bit AS and won't fix 48-bit one.  So we really need something more
>>>>>>> dynamic.
>>>>>>>
>>>>>>> --- libsanitizer/asan/asan_allocator.h  (revision 219833)
>>>>>>> +++ libsanitizer/asan/asan_allocator.h  (working copy)
>>>>>>> @@ -100,6 +100,10 @@
>>>>>>>  # if defined(__powerpc64__)
>>>>>>>  const uptr kAllocatorSpace =  0xa0000000000ULL;
>>>>>>>  const uptr kAllocatorSize  =  0x20000000000ULL;  // 2T.
>>>>>>> +# elif defined(__aarch64__)
>>>>>>> +// Valid only for 42-bit VA
>>>>>>> +const uptr kAllocatorSpace =  0x10000000000ULL;
>>>>>>> +const uptr kAllocatorSize  =  0x10000000000ULL;  // 1T.
>>>>>>>  # else
>>>>>>>  const uptr kAllocatorSpace = 0x600000000000ULL;
>>>>>>>  const uptr kAllocatorSize  =  0x40000000000ULL;  // 4T.
>>>>>>> --- libsanitizer/sanitizer_common/sanitizer_platform.h  (revision 
>>>>>>> 219833)
>>>>>>> +++ libsanitizer/sanitizer_common/sanitizer_platform.h  (working copy)
>>>>>>> @@ -79,7 +79,7 @@
>>>>>>>  // For such platforms build this code with
>>>>>>> -DSANITIZER_CAN_USE_ALLOCATOR64=0 or
>>>>>>>  // change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here.
>>>>>>>  #ifndef SANITIZER_CAN_USE_ALLOCATOR64
>>>>>>> -# if defined(__aarch64__) || defined(__mips64)
>>>>>>> +# if defined(__mips64)
>>>>>>>  #  define SANITIZER_CAN_USE_ALLOCATOR64 0
>>>>>>>  # else
>>>>>>>  #  define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64)
>>>>>>> @@ -88,10 +88,10 @@
>>>>>>>
>>>>>>>  // The range of addresses which can be returned my mmap.
>>>>>>>  // FIXME: this value should be different on different platforms,
>>>>>>> -// e.g. on AArch64 it is most likely (1ULL << 39). Larger values will 
>>>>>>> still
>>>>>>> work
>>>>>>> +// e.g. on AArch64 it is most likely (1ULL << 42). Larger values will 
>>>>>>> still
>>>>>>> work
>>>>>>>  // but will consume more memory for TwoLevelByteMap.
>>>>>>>  #if defined(__aarch64__)
>>>>>>> -# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL 
>>>>>>> <<
>>>>>>> 39)
>>>>>>> +# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL 
>>>>>>> <<
>>>>>>> 42)
>>>>>>>  #else
>>>>>>>  # define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL 
>>>>>>> <<
>>>>>>> 47)
>>>>>>>  #endif
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because this project is configured to send all
>>>>>>> issue notifications to this address.
>>>>>>> You may adjust your notification preferences at:
>>>>>>> https://code.google.com/hosting/settings
>>>>>>>
>>>>>>> --
>>>>>>> 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.
>>>>>>
>>>>>> --
>>>>>> 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.
>>>>>
>>>>> --
>>>>> 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.
>>
>> regards,
>> Venkat.

-- 
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.

Reply via email to