similar to: RFC: Sanitizer-based Heap Profiler

On Wed, Jul 8, 2020 at 6:30 PM Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 24, 2020 at 4:58 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi all, >> >> I've included an RFC for a heap profiler design I've been working on in >> conjunction with David Li. Please send any questions or feedback. For >>

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

Hi, Teresa, This looks really useful. It seems like this general infrastructure could be useful for diagnosing places where we have a lot of false sharing too. This could be between cores, sockets, or devices. Looking forward, especially with HMM and support under Linux for transparent unified memory between CPUs and accelerators, I anticipate we'll end up looking for places where some

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

On Fri, May 4, 2018 at 7:09 PM Walter Lee <waltl at google.com> wrote: > On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com> wrote: > > > On RAM... > > > You chose the 32-byte shadow granularity to reduce the RAM overhead, > > but I am afraid this will actually increase it due to extra alignment > requirements, > > especially if an

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

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

Hi I am using SanitizerCoverage feature supported by clang to get the basicblock coverage. my tested binaries are spec cpu2006. I compiled the binary with the option COPTIMIZE = -O0 -fsanitize=address -fsanitize-coverage=bb -flto -fno-strict-aliasing -std=gnu89 -gdwarf-3 After the compiling process is end. I run the 400.perlbench. with the command ASAN_OPTIONS=coverage=1 ./perlbench.

Hi If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

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

On 11 February 2016 at 17:08, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 11, 2016 at 5:53 AM, Dan Liew via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> > Can you somehow verify that this heap-use-after-free is happening? >> > E.g. print all the pointer values coming from memory::allocate, coming >> > into >> >

I ran our test suite with grain of 8 and 32, and more tests were able to avoid running out of memory with grain of 32 than 8. The ones that run out of memory on 8 but not 32 all failed trying to allocate a large region from the heap (350M). I haven't had any tests that run out of memory for other reasons. Given that, I will check in the current selected granularity of 32. I will try grain

On RAM... You chose the 32-byte shadow granularity to reduce the RAM overhead, but I am afraid this will actually increase it due to extra alignment requirements, especially if an average allocation on your typical application is small. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN.

Hi Kostya, >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch >> wrote: > >> Dear LLVM developers, >> >> We've applied the feedback we received on Phabricator on the SafeStack >> patches, >> > >Did you investigate the possibility of moving the transformation from >codegen to the LLVM level, i.e. the same level

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

On 31 Jul 2017, at 19:26, Hans Wennborg <hans at chromium.org> wrote: > > On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric <dimitry at andric.com> wrote: >> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>> 5.0.0-rc1 has just been tagged. >>> >>> Please build, test and upload binaries

I hadn't heard this before. If I use clang with -fsanitize=address to build my program, and then run my program, what difference does it make for the execution of my program whether the compiler itself was instrumented or not? Do you mean that ASAN runtime itself should be instrumented, since your program loads that at runtime? On Tue, Jul 7, 2020 at 2:04 PM Mitch Phillips <mitchp at

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test