[GHC] #13599: Something is fishy in Windows hLock implementation

[GHC]

#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