#13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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 (7e273ea28fe3630a8fede75ed28f471b7be21b5f) due to mysterious `ERROR_LOCK_INVALID_RANGE` errors on Harbormaster. While the fix in 7e273ea28fe3630a8fede75ed28f471b7be21b5f 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13599 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler