System.IO.openFile not safe with asynchronous exceptions; leaves inconsistent state
System.IO.openFile obtains a file descriptor and locks the inode inside the ghc's runtime state. Interrupting it with an asynchronous exception may cause leaking of the FD or wrongly keeping the inode locked.
Specifically, there is a scenario where the FD is closed but the inode is left locked in the ghc runtime. This is inconsistent state, broken invariant. If the file underlying the (closed) FD is deleted, subsequent
openFile call for a completely unrelated file name with
WriteMode can result in:
openFile: resource busy (file is locked) (if the filesystem reuses the inode).
The repro script linked below fails reliably with the error only on Linux. On OSX I observed running out of file descriptors instead ("too many open files").
I have prepared a fix, which is mostly applying masking and adding some cleanup. I'll create a PR.
Steps to reproduce
openFile, delete the created file, open a new file with WriteMode.
openFile: resource busy (file is locked)
This only fails sometimes. More likely on multi core machines.
Opening a new file (creating) for writing should not fail with
file is locked.
- GHC version used: 8.8.3
- Operating System: linux
- System Architecture: amd64