Due to recent fail of strcspn-2 (http://lab.llvm.org:8011/builders/sanitizer-ppc64-linux1/builds/7321/steps/check-asan%20in%20gcc%20build/logs/stdio) I've modified recently added unit tests for str interceptors to be more deterministic.
Details
Diff Detail
Event Timeline
OI would be great if someone investigated the "s3" point in my other comment, but this change alone should make the tests much more stable, so LGTM.
test/asan/TestCases/strcasestr-1.c | ||
---|---|---|
21 | I missed the original code review, but this "s3" business looks highly suspicious. Firstly, it is not good to rely on the order of variable declarations in the function body, compiler definitely does not promise anything about that. Secondly, if ASan may say that access overflows s3 - I'd treat this as a bug in the tool. Why does it happen? COMMON_INTERCEPTOR_READ_* should point to the first poisoned byte in the memory range, which should be the first byte after the end of s1. |
test/asan/TestCases/strcasestr-1.c | ||
---|---|---|
21 | I think we do need to put stopping zero byte somehow to ensure that e.g. underlying Glibc's strcasestr always terminates. Any suggestions how to achieve this in a cleaner way? Perhaps set last byte of s1's redzone to 0 in a noinline no_sanitize_address helper function? Overflow in s3 is strange indeed. |
test/asan/TestCases/strcasestr-1.c | ||
---|---|---|
21 | Maybe just allocate a larger buffer for the string and __asan_poison part of it. The report would just say "wild address" though, without a reference to s1/s2 variables. |
test/asan/TestCases/strcasestr-1.c | ||
---|---|---|
21 | Ah, right. Mash is on vacation so I guess I'll commit what we have meanwhile. |
I missed the original code review, but this "s3" business looks highly suspicious. Firstly, it is not good to rely on the order of variable declarations in the function body, compiler definitely does not promise anything about that. Secondly, if ASan may say that access overflows s3 - I'd treat this as a bug in the tool. Why does it happen? COMMON_INTERCEPTOR_READ_* should point to the first poisoned byte in the memory range, which should be the first byte after the end of s1.