search for: malloc_context_size

...w || || `[0x001200000000, 0x0013ffffffff]` || ShadowGap || || `[0x001000000000, 0x0011ffffffff]` || LowShadow || || `[0x000000000000, 0x000fffffffff]` || LowMem || MemToShadow(shadow): 0x001200000000 0x00123fffffff 0x001280000000 0x0013ffffffff redzone=16 max_redzone=2048 quarantine_size=256M malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 1000000000 ==29184==ERROR: AddressSanitizer failed to allocate 0xc00000000 (51539607552) bytes at address 1400000000 (errno: 12) ==29184==ReserveShadowMemoryRange failed while trying to map 0xc00000000 bytes. Perhaps you're using ulimit -v...

...the results >> here. > > I ended up increasing the limit to 2^20, because the max allocation for large objects is around 100G on those hosts. With that done, i hit an issue where adding stacks to the StackDepot became a visible bottleneck after a few hours. To solve that, i've set `malloc_context_size=0`, because we're not tracking leaks, and in our experience getting the call site of the ASAN report carries enough information to diagnose the issue. With these two changes, the build is behaving as expected. If you think it's worth doing, i'm happy to post a patch for the constant inc...

...ONS: debug=1,verbosity=1 ==28210==AddressSanitizer: libc interceptors initialized || `[0x20000000, 0xffffffff]` || HighMem || || `[0x04000000, 0x1fffffff]` || HighShadow || || `[0x00040000, 0x03ffffff]` || ShadowGap || MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 0 ==28210==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==28210==Process memory map follows: 0x00008000-0x0000f000 /data/data/djpeg 0x0000f000-0x00010000 /data/data/djp...

...f6fff]` || ShadowGap || || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || || `[0x000000000000, 0x00007fff7fff]` || LowMem || MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff redzone=16 max_redzone=2048 quarantine_size_mb=256M thread_local_quarantine_size_kb=1024K malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 0x7fff8000 ==3401806==Installed the sigaction for signal 11 ==3401806==Installed the sigaction for signal 7 ==3401806==Installed the sigaction for signal 8 ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; local=0x7fff3c75924...

On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote: > On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> > wrote: > > +Aleksey, who has been dealing with the allocator recently. > > > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > > check failure, it means that

...| LowShadow || >> || `[0x000000000000, 0x00007fff7fff]` || LowMem || >> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff >> redzone=16 >> max_redzone=2048 >> quarantine_size_mb=256M >> thread_local_quarantine_size_kb=1024K >> malloc_context_size=30 >> SHADOW_SCALE: 3 >> SHADOW_GRANULARITY: 8 >> SHADOW_OFFSET: 0x7fff8000 >> ==3401806==Installed the sigaction for signal 11 >> ==3401806==Installed the sigaction for signal 7 >> ==3401806==Installed the sigaction for signal 8 >> ==3401806==T0: stack [0x...

...10==AddressSanitizer: libc interceptors initialized > || `[0x20000000, 0xffffffff]` || HighMem || > || `[0x04000000, 0x1fffffff]` || HighShadow || > || `[0x00040000, 0x03ffffff]` || ShadowGap || > MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff > red_zone=16 > malloc_context_size=30 > SHADOW_SCALE: 3 > SHADOW_GRANULARITY: 8 > SHADOW_OFFSET: 0 > ==28210==Shadow memory range interleaves with an existing memory > mapping. ASan cannot proceed correctly. ABORTING. > ==28210==Process memory map follows: > 0x00008000-0x0000f000 /data/data/djpeg >...

On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> wrote: > +Aleksey, who has been dealing with the allocator recently. > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > check failure, it means that you've allocated (and did not deallocate) 2^18 > large heap regions, each *at least* (2^17+1) bytes. > This means, that

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

Hi, The 6.0.1-rc2 release has been tagged. Testers may begin testing and reporting results. -Tom

Hi, I've just tagged the 6.0.1-rc1 release. Testers may begin testing and uploading binaries. Also, any tester who has not tested 5.0.2-rc1 and would like to do so please try to do this before Friday, because I would like to tag 5.0.2-final then. As a reminder to users and developers, May 18 is the deadline for submitting merge requests for 6.0.1, so there is still time to get bug fixes

...:: TestCases/large_func_test.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/log-path_test.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/longjmp.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/lsan_annotations.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/malloc_context_size.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/malloc_fill.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/max_redzone.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/memcmp_strict_test.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/memcmp_test.cc Addre...

On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >>