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 ghc-pkg with procmon suggests that the issue is a negative offset being passed to LockFile. Moreover, 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.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	highest
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	arybczak
Operating system
Architecture