Re: Asan initialization broken on Android?

On Tue, Jul 20, 2021 at 1:17 AM Dmitry Vyukov wrote: > The error reported by buildbot is: > > = > ==26030==ERROR: AddressSanitizer: SEGV on unknown address 0xeaf5 > (pc 0xeadd3514 bp 0xc83e6c68 sp 0xc83e6c00 T-1) > ==26030==The

Re: Enabling Address Sanitizer in AudioFlinger

Hi, * ASan in Android 10 (or even Android 11) does not support leak detection. The current AOSP master branch might. * Leak detection is done when a program exits, which audioflinger never does. There is an API to force a leak check at runtime. On Mon, Feb 8, 2021 at 10:05 PM varsha vanga

Re: Crash in application's startup code around Asan red zone

I think this "malloc.c" could be a problem. The way control jumped from _dlerror_run to a non-ASan malloc is definitely not right. On Fri, Jan 15, 2021 at 12:43 PM Jeffrey Walton wrote: > > What does /proc/$PID/maps say? > > (gdb) info inferior > Num Description Executable > * 1

Re: Crash in application's startup code around Asan red zone

> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || > 0x7fff8000(0xbc0) == 0x10007fff7bc0 Access is within HighShadow, which should be writable. What does /proc/$PID/maps say? On Fri, Jan 15, 2021 at 12:33 PM Jeffrey Walton wrote: > Thanks again Evgeniy, > > > Try running with

Re: Crash in application's startup code around Asan red zone

0x7fff8000(0xbc0) looks fine - it's a shadow address for ~near top of the main thread stack. Perhaps ASan did not initialize in time? What's the backtrace of the crash? Try a breakpoint on __asan_init. Try running with ASAN_OPTIONS=verbosity=2,debug=1, it should print the memory layout.

Re: SEGV in glibc's _int_free(), without use of RTLD_DEEPBIND

ted source code? > If you can show that this thing that is being freed has been allocated with ASan's malloc, then certainly. > Zach > > On Thu, Mar 26, 2020 at 3:39 PM 'Evgenii Stepanov' via address-sanitizer < > address-sanitizer@googlegroups.com> wrote: > >> This might h

Re: SEGV in glibc's _int_free(), without use of RTLD_DEEPBIND

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

Re: SEGV in glibc's _int_free(), without use of RTLD_DEEPBIND

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

Re: How much extra memory do ASAN builds use?

Depends on the application a lot. There is a large constant overhead component; then there is the quarantine that has the upper per-thread limit, which means long-running processes tend to use more RAM with time, but also saturate at some point. This can be tuned with runtime flags. We often see

Re: Integrate Address Sanitizer into Android N

Hi, check if the build file under prebuilts/clang/host/linux-x86 mentions libclang_rt.asan-i686-android.so It might have not been there yet. If that's the case, you can try to engage in software archaeology and figure out how to build the missing library at the matching version (it needs to be

Re: "failed to allocate" and "unknown-crash"

kMaxAllowedMallocSize is pretty much arbitrary. It looks like you are running with allocator_may_return_null=1 (not the default!), and your program does not handle malloc() returning NULL. On Sat, Dec 1, 2018 at 7:47 AM xfan wrote: > > Asan reports the following error: > > ==6113== WARNING:

Re: Performance slowdown of ASAN

As Kostya said, ASan overhead is not limited to instrumentation of memory access instructions. One other case that comes to mind: too many unique malloc/free stack traces can put pressure on StackDepot. I'd recommend looking at some of the outliers with a CPU profiler. On Mon, Sep 3, 2018 at

Re: [EXTERNAL]: Issues booting ASAN enabled build even with "mm: Revert x86_64 and arm64 ELF_ET_DYN_BASE base" applied

Btw, the attachment is lost, but I assume it is the same problem. On Thu, Oct 26, 2017 at 11:17 AM, Evgenii Stepanov wrote: > Yes. 32-base base is still a problem specifically on Android. The best > option is to revert it, too. We are also investigating a fix on the > ASan

Re: LSan not reporting leaks on Android N

LSan is not enabled on Android, see https://github.com/google/sanitizers/issues/379 It's kind of on our TODO list, but I can not say when we might finally get to it. On Wed, Oct 4, 2017 at 2:48 PM, 'Primiano Tucci' via address-sanitizer wrote: > Hi. > I am

Re: is that false alarm of "container-overflow"?

it - begin = 0, capacity = 4, size = 2 0x62503992 is located 4242 bytes inside of 8448-byte region [0x62502900,0x62504a00) vector element size = 8448 / 4 = 2112 bytes offset 4242 belongs to the 3rd element, which is actually out of bounds when size == 2. Looks like a true positive.

Re: is that false alarm of "container-overflow"?

I don't know how common this algorithm is, given that it does N^2 operations to remove N elements. But I don't see any container overflow here. Could you post the actual report? Does this look relevant to your setup:

Re: Extending LSAN to report where memory is leaked?

Interesting idea, but I feel it would have very significant overhead. Basically, every time a region of memory is written or deallocated, we would need to scan the previous contents for anything that looks like a heap pointer and update metadata for those allocations. No need to track references -

Re: Address Sanitizer clashes with Dataflow Sanitizer

On Fri, Jun 9, 2017 at 4:26 PM, hariri via address-sanitizer wrote: > Thanks for your reply Evgeniy. > >> It could be possible > to hack something, but it does not sound easy > > Could you please give me some pointers into what needs to be hacked to make > this

Re: Address Sanitizer clashes with Dataflow Sanitizer

Hi, these tools were not designed to work together. It could be possible to hack something, but it does not sound easy. In particular, they use different techniques for intercepting libc calls and it's not clear to me how one would tie them together. On Fri, Jun 9, 2017 at 8:52 AM, hariri via

Re: ASan on android without rooting device

Oh, and the downside is slow startup. With the wrap property, any process startup takes several extra seconds to reload all the base classes. On Thu, May 18, 2017 at 12:48 PM, Evgenii Stepanov wrote: > Hi, > > There is a system property that lets you prepend anything to the >

Re: ASan on android without rooting device

Hi, There is a system property that lets you prepend anything to the zygote command line for a specific application, "wrap.". It requires a rooted device, but does not require remounting system r/w. In theory, this requirement could be relaxed by allowing wrapping apps even on a locked device

Re: who calls asan.module_ctor to do the asan module init?

A pointer to asan.module_ctor goes into .init_array or .ctors as appropriate for the platform. On Thu, Nov 10, 2016 at 1:23 AM, steven shi wrote: > Hello, > I'm enabling the asan in my firmware, and I meet a issue that the > asan.module_ctor() as below is missing in my

Re: logging both to console and logfile (feature request)

Does logging to syslog instead of a file work for you? That's what we do in a similar situation on Android. The flag may work on linux already, if not it should be fixed. On Mon, Nov 2, 2015 at 11:09 AM, Hanno Böck wrote: > On Sun, 1 Nov 2015 20:50:08 -0800 > Konstantin