I see now. Thanks for clarifying that.
Zach
On Fri, Mar 27, 2020 at 12:17 PM 'Evgenii Stepanov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:
>
> On Fri, Mar 27, 2020 at 8:47 AM Zach Laine
> wrote:
>
>> Thanks. In case it matters, I'm using GCC, and the same thing
On Fri, Mar 27, 2020 at 8:47 AM Zach Laine
wrote:
> Thanks. In case it matters, I'm using GCC, and the same thing happens
> with and without -static-libasan.
>
> To be 100% clear, do you agree that it is very unlikely that this is a bug
> fixable by changing the instrumented source code?
>
If
Thanks. In case it matters, I'm using GCC, and the same thing happens with
and without -static-libasan.
To be 100% clear, do you agree that it is very unlikely that this is a bug
fixable by changing the instrumented source code?
Zach
On Thu, Mar 26, 2020 at 3:39 PM 'Evgenii Stepanov' via
This might happen if something messed with symbol exports from the main
executable (if you are using llvm and asan runtime library is linked
statically). Things like version scripts, etc.
On Thu, Mar 26, 2020 at 1:38 PM Evgenii Stepanov wrote:
> It looks like free() in libc got an address that
It looks like free() in libc got an address that was allocated with ASan's
malloc().
Yes, things like RTLD_DEEPBIND are known to cause this.
Check how the call from #1 to #0 happened, and why did it bind to a libc.so
symbol, and not to the asan's free().
On Thu, Mar 26, 2020 at 1:22 PM Zach
I'm trying to figure out if what I'm seeing is a legitimate SEGV -- that
is, one based on the code being instrumented -- or a crash due to a build
or run environment that is hostile to ASan.
The crash is happening in our code on a call to free(), and is showing up
in ASan runs as a SEGV in
