In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling back to a
"pread()", but it was failing to check the result of that system call.
This meant that the function would return "success" even though the read
operation failed, and it returned a buffer full of uninitialized memory.
Details
- Reviewers
rnk dblaikie - Commits
- rG51d7398f630c: Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"
rL369370: Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"
rG46bfdb956cb8: MemoryBuffer: Add a missing error-check to getOpenFileImpl
rL368977: MemoryBuffer: Add a missing error-check to getOpenFileImpl
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 36751 Build 36750: arc lint + arc unit
Event Timeline
PS: I discovered this when accidentally trying to read a directory, but it is not possible to write a portable test for that, as some BSDs will actually allow you to do that, so the test is written via a write-only file handle instead.
It looks like this changed caused 30 or so of the tests to fail on the Windows bot. It was already broken, so you wouldn't have gotten an email:
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7851
Oh my... I was doing this to fix a different LLDB bug :/. Lemme boot up windows to see what's happening here...
Ok, I have an idea what's going on. There's a difference in the behavior of readNativeFileSlice on windows&posix, and neither of them really do what MemoryBuffer expects here. I don't have time to fix this today so I'll revert and get back to this tomorrow. Thanks for the heads up.