On Mon, Aug 18, 2014 at 9:42 AM, Yury Gribov <y.gri...@samsung.com> wrote: > On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote: >> >> On the compile farm, ASAN tests seem to fail a lot like: >> >> FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern >> test, is ==31166==ERROR: AddressSanitizer failed to allocate >> 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: >> 12) >> ==31166==ReserveShadowMemoryRange failed while trying to map >> 0xdfff0001000 bytes. Perhaps you're using ulimit -v >> , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*( >> >> The problem is that those addresses and sizes are very random, so when >> I compare the test results of a pristine trunk with a patched one, I >> get: >> >> New tests that FAIL: >> >> unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output >> pattern test, is ==12875==ERROR: AddressSanitizer failed to allocate >> 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: >> 12) >> unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output >> pattern test, is ==18428==ERROR: AddressSanitizer failed to allocate >> 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: >> 12) >> [... hundreds of ASAN tests that failed...] >> >> Old tests that failed, that have disappeared: (Eeek!) >> >> unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output >> pattern test, is ==30142==ERROR: AddressSanitizer failed to allocate >> 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: >> 12) >> unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output >> pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate >> 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: >> 12) >> [... the same hundreds of tests that already failed before...] >> >> The above makes very difficult to identify failures caused by my patch. >> >> Can we remove the "==...." part of the error? This way compare_tests >> will ignore the failures. >> >> Alternatively, I could patch compare_tests to sed out that part before >> comparing. Would that be acceptable? >> >> Cheers, >> >> Manuel. >> > > Added Sanitizer folks. Frankly it'd be cool if dumping PIDs and addresses > could be turned off. >
Could you please name a reason for that? Doing so complicates the debugging of multi-process applications but doesn't bring any obvious advantages. -- Alexander Potapenko Software Engineer Google Moscow