[GHC] #13599: Something is fishy in Windows hLock implementation
#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
#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
#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 bgamari): Great catch! I can take it from here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13599#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 Ben Gamari
#13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13599#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): Merged in e5732d2a28dfb8a754ee73e124e3558222a543bb. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13599#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC