Address sanitizer failures in readdir and statfs on Mac

I see address sanitizer failures with TOT clang in readdir_r on Mac OS 10.9 like the following:

asan-mavericks.diff (1.12 KB)

+glider
Are you certain that this is not a real bug in your code?Could you provide a minimal test case?
Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on your machine?
(or, simply, does ‘make check-asan’ work?)

This might be something in 10.9 that has changed since 10.8.
Afaict, we are still not testing asan on 10.9 (glider?)
Could you please send a preprocessed source of a test calling readdir_r so that I can see the definition of struct dirent?

Looking at your report I see:
WRITE of size 48830 at 0x11617988 thread T0
0x11617988 is located 0 bytes to the right of 520-byte region [0x11617780,0x11617988)

So, somewhere in your heap you’ve allocated 520 bytes of memory for dirent.
Then our readdir_r interceptor does this:

int res = REAL(readdir_r)(dirp, entry, result);
if (!res) {
COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));
if (*result)
COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);
}

Since we see “WRITE of size 48830”, this is likely the second “COMMON_INTERCEPTOR_WRITE_RANGE”
with d_reclen=48830. That’s quite unexpected I think.

–kcc

We’re running ASan tests on 10.9, but IIRC Chrome bots are still on 10.8.
However I doubt there’s much difference between these two OSX versions.

The code in question is in Qt. I think that it must have been a real bug in the code since I can no longer reproduce after trying the most recent version of Qt. I also haven’t been able reproduce the error in a minimal sample. I’m pretty sure that I started seeing the issue when I switched from 10.8 to 10.9, but that doesn’t mean that it’s not a bug in the client code.

On a slightly different topic, I’m a little confused about why I even get errors in Qt the first place since it was built without address sanitizer instrumentation. I didn’t expect to see any errors there. Is there any way that I can ignore errors in third party libraries like this?

In any case, I apologize for the false alarm. Thanks for the help!

Jason

There are intercepors for various uninstrumented libc functions invisible to the tool otherwise. They are used to report addressability bugs in the data passed into libc.
Some interceptors can be disabled using ASAN_OPTIONS (not sure about readdir(), need to look that up), though you can’t disable them just for third party libraries.
Keep in mind that although you sometimes can make ASan ignore a heap corruption this doesn’t fix the bug, and something may break later due to this wild write.