[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
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by arybczak):

 Well, this is embarrassing. I just took a look at the definition of
 `fillBytes` and it looks like the arguments in `lockImpl` are passed
 backwards, so instead of filling sizeof_OVERLAPPED bytes with value 0 it
 fills 0 bytes with value sizeof_OVERLAPPED, leaving it effectively
 uninitialized.

 I believe the following should do the trick:
 {{{#!diff
 diff --git a/libraries/base/GHC/IO/Handle/Lock.hsc
 b/libraries/base/GHC/IO/Handle/Lock.hsc
 index 5608c1810c..3e790a233a 100644
 --- a/libraries/base/GHC/IO/Handle/Lock.hsc
 +++ b/libraries/base/GHC/IO/Handle/Lock.hsc
 @@ -123,7 +123,7 @@ lockImpl h ctx mode block = do
    FD{fdFD = fd} <- handleToFd h
    wh <- throwErrnoIf (== iNVALID_HANDLE_VALUE) ctx $ c_get_osfhandle fd
    allocaBytes sizeof_OVERLAPPED $ \ovrlpd -> do
 -    fillBytes ovrlpd (fromIntegral sizeof_OVERLAPPED) 0
 +    fillBytes ovrlpd 0 sizeof_OVERLAPPED
      let flags = cmode .|. (if block then 0 else #{const
 LOCKFILE_FAIL_IMMEDIATELY})
      -- We want to lock the whole file without looking up its size to be
      -- consistent with what flock does. According to documentation of
 LockFileEx
 @@ -131,7 +131,7 @@ lockImpl h ctx mode block = do
      -- not an error", however some versions of Windows seem to have
 issues with
      -- large regions and set ERROR_INVALID_LOCK_RANGE in such case for
      -- mysterious reasons. Work around that by setting only low 32 bits.
 -    fix $ \retry -> c_LockFileEx wh flags 0 0xffffffff 0x0 ovrlpd >>=
 \case
 +    fix $ \retry -> c_LockFileEx wh flags 0 0xffffffff 0xffffffff ovrlpd
 >>= \case
        True  -> return True
        False -> getLastError >>= \err -> if
          | not block && err == #{const ERROR_LOCK_VIOLATION} -> return
 False
 }}}

 Should I make a Phab patch or you can do it?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13599#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler