I'm hitting this in local testing. Interestingly going back even further than Mar 3 still shows this issue so perhaps something changed in a dependency.

Taking a look.

+manojgupta

I've been able to reproduce this issue and found that it's a heap corruption:

*** Error in `/usr/sbin/authpolicy_parser': malloc(): memory corruption: 0x000055d09f03bec0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75492)[0x7fed4e249492]
/lib64/libc.so.6(+0x7b611)[0x7fed4e24f611]
/lib64/libc.so.6(+0x7d815)[0x7fed4e251815]
/lib64/libc.so.6(__libc_malloc+0x55)[0x7fed4e253975]
/usr/lib64/libbase-core-395517.so(ShimCppNew+0x22)[0x7fed4e9fa892]
======= Memory map: ========
Aborted

After doing a clean rebuild, the issue was gone, so I'm assuming it's a problem with incremental builds only (matches your observation of failing tryjobs in the description).

I'm wondering whether it could be related to  https://crbug.com/807685  and https://chromium-review.googlesource.com/900684, which swaps out the memory allocator in ASAN builds. Uprev'ing the libchrome.ebuild doesn't cause stuff to rebuild that depends on libchrome, so maybe we're ending up in a spot where some packages use the old allocator and some use the new one.

A fix might be to depend on >=chromeos-base/libchrome-395517-r22 (although I'm not sure how/where to set that since libchrome is a bit non-standard.

WDYT?

Right now, the custom allocator is disabled only for asan builds (use asan && epatch ). I suspect it should be disabled completely irrespective of asan.

I tried disabling the allocator, but that just gave me a different error message.

Given that the incremental builds looks green again and that a clean rebuild fixes it, are you OK to close this out?