Something is fishy in Windows hLock implementation
Ever since we merged the package database locking patch (#13194) I have suspected that something isn't quite right in the locking logic on Windows. The first suspicious sign is that we had to limit the locking range (7e273ea2) due to mysterious
ERROR_LOCK_INVALID_RANGE errors on Harbormaster. While the fix in 7e273ea2 seemed to make the issue disappear, we never were able to pin down the issue.
However, now I'm seeing the
ERROR_LOCK_INVALID_RANGE issue once again on my local Windows during
binary-dist-prep. In particular, it
binary-dist-prep seems to reliably fail while registering the
compiler directory. Watching the system calls performed by
procmon suggests that the issue is a negative offset being passed to
LockFile calls from previous
ghc-pkg invocations show other, apparently random offset values being passed. The offset is passed to
LockFileEx (the interface used by our
hLock implementation) via an
OVERLAPPED structure, which we locally allocate and zero prior to the
LockFileEx call. I still haven't worked out where these random values are coming from.