According to man freopen, passing NULL instead of a filename is valid, however the current implementation of the interceptor assumes this parameter is non-NULL. Let's fix that and add a test case.
Details
- Reviewers
kcc glider samsonov - Commits
- rGb79932addf6f: [asan] Fix the freopen interceptor to allow NULL instead of a filename
rG4c0cdec1384f: [asan] Fix the freopen interceptor to allow NULL instead of a filename
rCRT246435: [asan] Fix the freopen interceptor to allow NULL instead of a filename
rCRT242787: [asan] Fix the freopen interceptor to allow NULL instead of a filename
rL246435: [asan] Fix the freopen interceptor to allow NULL instead of a filename
rL242787: [asan] Fix the freopen interceptor to allow NULL instead of a filename
Diff Detail
- Repository
- rL LLVM
Event Timeline
The case of path==NULL is not covered in the Ubuntu manpage for freopen, but this behavior is mandated by POSIX and is in fact implemented in Glibc.
Therefore LGTM
test/asan/TestCases/Posix/freopen.cc | ||
---|---|---|
10 ↗ | (On Diff #30253) | Please add the return statement. |
Hm, the Linux buildbot didn't like this change: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/19256/steps/check-asan%20in%20gcc%20build/logs/stdio
Interestingly, only the i386 variant failed. Could it be that that system's libc really doesn't support NULL for freopen? Alexander, could you help me out here? I reverted the patch until we figure this out.
Thanks!
When built with -m32 and without ASan, this testcase does not crash for me.
Trying to reproduce with ASan.
Hi Kuba,
the crash reproduced for me, but I couldn't find the cause, and then I
got distracted.
I'll try to take a look again next week.
Alex
OK, I was able to reproduce the i386 Linux test failure. It looks like it has little to do with the actual patch/fix, but instead it's a more general issue with versioned symbols from glibc – freopen is a versioned symbol (and incompatible between versions), and when it's intercepted, a wrong version is called. Even this fails (with or without this patch):
FILE *fp = fopen("/dev/null", "w"); freopen("/dev/null", "r", fp); fclose(fp);
This seems to be a Linux-specific issue, and frankly, I don't know what to do about it. In the meantime, I'm suggesting to commit this patch without the testcase. Updating the diff.
What's the proper way to mark a test as disabled? I'm only aware of XFAIL and REQUIRES marks.
I don't think that'll work, since this only fails on i386 Linux and works fine on other platforms and architectures...
Marking the patch with REQUIRES: asan-64-bits to skip the test on i386 Linux (where it fails due to an unrelated issue with glibc versioned symbols). XFAIL wouldn't work here, because the test actually passes on all other platforms/architectures.