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 |