GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:34:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10639Tight (non-allocating) loop freezes the scheduler2019-07-07T18:34:55Zgizmo.mk0Tight (non-allocating) loop freezes the schedulerHere is a program that spawns a thread from the main thread, which tries to constantly write out a message to the console.
```hs
module Main where
import Control.Concurrent (forkIO)
main :: IO ()
main = do
_ <- forkIO $ runForever...Here is a program that spawns a thread from the main thread, which tries to constantly write out a message to the console.
```hs
module Main where
import Control.Concurrent (forkIO)
main :: IO ()
main = do
_ <- forkIO $ runForever $ putStrLn "Hey"
runForever $ return ()
runForever :: IO () -> IO ()
runForever action = action >> runForever action
```
If you compile it with 'ghc main', it works correctly - it prints out the message continuously, and you can terminate it by pressing Ctrl-C. However, if you compile it with 'ghc -O main' (or -O2, or -O3...), it doesn't print out anything, and the only way to exit is to kill the process from Task Manager.
This was reproducable with GHC 7.10.1, on a Windows 7 x64 machine, with an AMD A4-5300 APU.
''EDIT: As it turns out, using "yield" instead of "return ()" solves the problem. It seems I misunderstood how forkIO works. However, I'm not sure if the current working is intentional or not, so I think I should leave this ticket open - just to be on the safe side.''https://gitlab.haskell.org/ghc/ghc/-/issues/10629threadWaitRead throws BlockedIndefinitelyOnMVar2019-07-07T18:34:57ZFacundo DomínguezthreadWaitRead throws BlockedIndefinitelyOnMVarIn a project using the network-transport-tcp package, I'm observing `threadWaitRead` throw the exception `BlockedIndefinitelyOnMVar`.
The call stack is roughly:
```
...
n-t-tcp:Network.Transport.TCP.handleIncomingMessages
n-t-tcp:Netwo...In a project using the network-transport-tcp package, I'm observing `threadWaitRead` throw the exception `BlockedIndefinitelyOnMVar`.
The call stack is roughly:
```
...
n-t-tcp:Network.Transport.TCP.handleIncomingMessages
n-t-tcp:Network.Transport.TCP.Internal.recvInt32
n-t-tcp:Network.Transport.TCP.Internal.recvExact
network:Network.Socket.ByteString:recv
network:Network.Socket.ByteString:recvInner
network:Network.Socket.Internal:throwSocketErrorWaitRead
base:Control.Concurrent:threadWaitRead
```
IIUC this would be an RTS bug. The socket file descriptor is healthy and works fine if the exception is caught and `threadWaitRead` is retried.
Unfortunately, I can only reproduce this in a particular cluster and with a rather complex test case while using the threaded runtime.
I'd appreciate any advice on inspecting the RTS code to scan for the cause of `BlockedIndefinitelyOnMVar` being thrown.
Of course, if someone can help explaining this behavior I'll be most thankful.Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10576REPL returns list of all imported names when operator completion requested2021-03-01T16:53:34ZGeraldusREPL returns list of all imported names when operator completion requestedWhen querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base...When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also.
In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge.
GHCi behaves similarly with following queries:
```
:complete repl "(>>"
:complete repl "Prelude.>>"
:complete repl "Prelude.(>>"
```
I only tested this on OS X 10.9, GHC 7.8.49.2.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/10553powerpc: getEnvironment empty when run in GHCi2019-07-07T18:35:22ZJoachim Breitnermail@joachim-breitner.depowerpc: getEnvironment empty when run in GHCiHi,
on powerpc (only), with ghc-7.8, we have this:
```
$ cat env.hs
import System.Environment
main = getEnvironment >>= print
$ runhaskell env.hs
[]
$ ./env
[("RESET","\\e[0m")...
```
This breaks the test suite of shake. Does anyone f...Hi,
on powerpc (only), with ghc-7.8, we have this:
```
$ cat env.hs
import System.Environment
main = getEnvironment >>= print
$ runhaskell env.hs
[]
$ ./env
[("RESET","\\e[0m")...
```
This breaks the test suite of shake. Does anyone feel like investigating this?
Also tracked at https://bugs.debian.org/789458https://gitlab.haskell.org/ghc/ghc/-/issues/10542Incorrect Unicode input on Windows Console2024-03-14T23:23:51ZptroevIncorrect Unicode input on Windows ConsoleTo reproduce:
- start a windows console
- change the console's font to a ttf unicode font, like "Lucida Console".
- type "chcp 65001" to set it to the UTF-8 code page.
- start ghci (same error appears when running compiled executable)
- ...To reproduce:
- start a windows console
- change the console's font to a ttf unicode font, like "Lucida Console".
- type "chcp 65001" to set it to the UTF-8 code page.
- start ghci (same error appears when running compiled executable)
- \> import System.IO (or GHC.IO.Handle)
- \> enc \<- mkTextEncoding "UTF8"
- \> hSetEncoding stdin enc
- \> getLine
- \> Фывфыв (or any international unicode sequence)
- \*\* Exception: \<stdin\>: hGetLine: end of file
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #4471 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect Unicode input on Windows Console","status":"New","operating_system":"","component":"Compiler","related":[4471],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["65001","chcp","cmd","getLine","stdin","utf-8","windows"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce:\r\n- start a windows console\r\n- change the console's font to a ttf unicode font, like \"Lucida Console\".\r\n- type \"chcp 65001\" to set it to the UTF-8 code page.\r\n- start ghci (same error appears when running compiled executable)\r\n- > import System.IO (or GHC.IO.Handle)\r\n- > enc <- mkTextEncoding \"UTF8\"\r\n- > hSetEncoding stdin enc\r\n- > getLine\r\n- > Фывфыв (or any international unicode sequence)\r\n*** Exception: <stdin>: hGetLine: end of file\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/10521Wrong results in strict Word8 storage on x642019-07-07T18:35:35ZVincentBerthoux2Wrong results in strict Word8 storage on x64The following snippet produce two different results in function of the compiler platform used:
```hs
import Data.Word( Word8 )
-- removing the bang patterns on V definition makes
-- the problem go away.
data V = V !Word8 !Word8 derivin...The following snippet produce two different results in function of the compiler platform used:
```hs
import Data.Word( Word8 )
-- removing the bang patterns on V definition makes
-- the problem go away.
data V = V !Word8 !Word8 deriving Show
toV :: Float -> V
toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where
coeff = significand d * 255.9999 / d
main :: IO ()
main =
print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ]
```
On GHC 7.10.1 x86 (under windows and Linux) the output is:
```
[V 145 124,V 189 128,V 137 128,V 132 126,V 233 127]
```
On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is:
```
[V 0 124,V 0 128,V 0 128,V 0 126,V 0 127]
```
The bug appear at the following optimisation levels:
- `-O1`
- `-O2`
- `-O3`
the results are the same at `-O0`
This bug was discovered in a bug report in the library JuicyPixels [https://github.com/Twinside/Juicy.Pixels/issues/98](https://github.com/Twinside/Juicy.Pixels/issues/98).
The same problem has been seen with GHC 7.10.2 RC17.10.2rwbartonrwbartonhttps://gitlab.haskell.org/ghc/ghc/-/issues/10517Unexpected behavior of unsafeCoerce converting Word32 to Word82019-07-07T18:35:36ZsvenkUnexpected behavior of unsafeCoerce converting Word32 to Word8The function `unsafeCoerce` behaves unexpected if it is used to convert `Word32` to `Word8`:
```hs
main = do
-- prints 135
print (fromIntegral (1234567 :: Word32) :: Word8)
-- prints 1234567
print (unsafeCoerce (1234567 :: Word...The function `unsafeCoerce` behaves unexpected if it is used to convert `Word32` to `Word8`:
```hs
main = do
-- prints 135
print (fromIntegral (1234567 :: Word32) :: Word8)
-- prints 1234567
print (unsafeCoerce (1234567 :: Word32) :: Word8)
```
On the other hand coercing `Ptr Word32` to `Ptr Word8` or the other way around works perfectly fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpected behavior of unsafeCoerce converting Word32 to Word8","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The function `unsafeCoerce` behaves unexpected if it is used to convert `Word32` to `Word8`:\r\n\r\n{{{#!hs\r\n\r\nmain = do\r\n -- prints 135\r\n print (fromIntegral (1234567 :: Word32) :: Word8)\r\n\r\n -- prints 1234567\r\n print (unsafeCoerce (1234567 :: Word32) :: Word8)\r\n}}}\r\n\r\nOn the other hand coercing `Ptr Word32` to `Ptr Word8` or the other way around works perfectly fine.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10444Text.Read.Lex.lex broken2019-07-07T18:35:53ZMatthew Farkas-DyckText.Read.Lex.lex broken```
Prelude> lex "&) = mempty"
[("&",") = mempty")]
Prelude> lex "∘) = mempty"
[]
```
I traced this problem to Text.Read.Lex.lex```
Prelude> lex "&) = mempty"
[("&",") = mempty")]
Prelude> lex "∘) = mempty"
[]
```
I traced this problem to Text.Read.Lex.lex8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10414Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)2019-07-07T18:36:02Zexio4Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)Compiling the test case with:
> ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs
Now, trying with some inputs and -N2
> $ ./ghc-bug 7 +RTS -N2
> =\> ghc-bug: \<\<loop\>\>
> $ ./ghc-bug 6 +RTS -N2
> =\> ghc-bug: \<\<loop\>\>
> $ ....Compiling the test case with:
> ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs
Now, trying with some inputs and -N2
> $ ./ghc-bug 7 +RTS -N2
> =\> ghc-bug: \<\<loop\>\>
> $ ./ghc-bug 6 +RTS -N2
> =\> ghc-bug: \<\<loop\>\>
> $ ./ghc-bug 5 +RTS -N2
> =\> 3125
> $ ./ghc-bug 5 +RTS -N2
> ghc-bug: \<\<loop\>\>
Reducing the number of capabilities to 1, it works for those inputs
> $ ./ghc-bug 7 +RTS -N1
As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [original testcase](http://lpaste.net/132564/) felt a bit more deterministic, but I think the testcase in the ticket is good enough)
I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian
Similar bug: #10218 (-fno-cse and -flate-dmd-anal didn't help with this)
```hs
import Control.Applicative
import Control.Monad
import Control.Parallel.Strategies
import System.Environment
newtype ParList a = ParList { unParList :: [a] }
nil :: ParList a
nil = ParList []
cons :: a -> ParList a -> ParList a
cons x (ParList xs) = ParList (x:xs)
instance Functor ParList where
fmap = liftM
instance Applicative ParList where
pure = return
(<*>) = ap
instance Monad ParList where
return = ParList . return
{- v code that doesn't work -}
(ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs >>= unParList . f))
--(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs))
{- ^ code that works -}
type Pair = (Int, [Int])
loop' :: Pair -> ParList Pair
loop' (size,qns) = go 1
where go n | n > size = nil
| otherwise = cons (size, n:qns) (go (n+1))
worker :: Int -> Pair -> [Pair]
worker n = unParList . go n
where go 1 = loop'
go n = loop' >=> go (n-1)
main :: IO ()
main = do
[n] <- (read <$>) <$> getArgs
print $ length (worker n (n,[]))
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10408The behavior of -ignore-dot-ghci and -ghci-script are weird2019-07-07T18:36:03ZZejun WuThe behavior of -ignore-dot-ghci and -ghci-script are weird```
$ for i in `seq 10`; do echo "print $i" > /tmp/$i.ghci; done
$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci
2
1
0
$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot-ghci
0
```
`-ghci-script` are e...```
$ for i in `seq 10`; do echo "print $i" > /tmp/$i.ghci; done
$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci
2
1
0
$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot-ghci
0
```
`-ghci-script` are executed in reverse order and are ignored when `-ignore-dot-ghci` is specified, while I expected that:
- `-ghci-script` are executed in the order they are specified;
- `-ignore-dot-ghci` only ignores the default .ghci files but still executes the scripts passed by `-ghci-script`.
I would like to change the behavior to the expected ones. But in case there are users relying on the old behavior, then it might be necessary to introduce different flags.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The behavior of -ignore-dot-ghci and -ghci-script are weird","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"watashi"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr","simonmar"],"type":"Bug","description":"{{{\r\n$ for i in `seq 10`; do echo \"print $i\" > /tmp/$i.ghci; done\r\n$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci\r\n2\r\n1\r\n0\r\n$ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot-ghci\r\n0\r\n}}}\r\n\r\n`-ghci-script` are executed in reverse order and are ignored when `-ignore-dot-ghci` is specified, while I expected that:\r\n* `-ghci-script` are executed in the order they are specified;\r\n* `-ignore-dot-ghci` only ignores the default .ghci files but still executes the scripts passed by `-ghci-script`.\r\n\r\nI would like to change the behavior to the expected ones. But in case there are users relying on the old behavior, then it might be necessary to introduce different flags.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10380"thread blocked indefinitely" exception while blocking on a socket2019-07-07T18:36:18Ztakano-akio"thread blocked indefinitely" exception while blocking on a socketFirst start a TCP server, e.g. nc.
```
% nc localhost -l 1234 > /dev/null
```
On another shell, compile the following program and run it:
```
% ghc -threaded sock.hs
% ./sock localhost 1234
receiver: thread blocked indefinitely in an ...First start a TCP server, e.g. nc.
```
% nc localhost -l 1234 > /dev/null
```
On another shell, compile the following program and run it:
```
% ghc -threaded sock.hs
% ./sock localhost 1234
receiver: thread blocked indefinitely in an MVar operation
```
```hs
{-# LANGUAGE ViewPatterns #-}
import Control.Applicative -- GHC 7.8 compatibility
import Control.Concurrent
import qualified Control.Exception as Ex
import Control.Monad
import qualified Data.ByteString.Char8 as S
import Network.Socket
import qualified Network.Socket.ByteString as Sock
import Network.BSD (getHostByName, hostAddresses)
import System.Environment
import System.Mem
main :: IO ()
main = do
[host, read -> fromInteger -> port] <- getArgs
sock <- connectTo host port
forkVerbose "sender" $ forever $ do
_ <- Sock.send sock $ S.replicate 40000 '0'
return ()
forkVerbose "receiver" $ forever $ do
dat <- Sock.recv sock 2048
putStrLn $ "received: " ++ show dat
forever $ do
threadDelay 1000000
performGC
forkVerbose :: String -> IO () -> IO ()
forkVerbose name act = void $ forkIO $ do act; msg "exiting normally"
`Ex.catch` \e -> msg $ show (e :: Ex.SomeException)
where
msg s = putStrLn $ name ++ ": " ++ s
connectTo :: HostName -> PortNumber -> IO Socket
connectTo hostName port = do
addr <- SockAddrInet port <$> lookupHost hostName
sock <- socket AF_INET Stream 0
connect sock addr
return sock
lookupHost :: String -> IO HostAddress
lookupHost name = do
hostInfo <- getHostByName name
case hostAddresses hostInfo of
[] -> error ("Invalid host name: " ++ name)
(a:_) -> return a
```
GHC 7.8.3 doesn't have this problem.
I suspect that this is a regression in the event manager. When there is an event, `GHC.Event.Manager.onFdEvent` seems to remove all callbacks associated to the `fd`, whether or not they match the current event. In the program above, the callback for `recv` may be removed permanently when the socket becomes ready for `send`ing, causing the "receiver" thread to deadlock.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"thread blocked indefinitely\" exception while blocking on a socket","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"First start a TCP server, e.g. nc.\r\n\r\n{{{\r\n% nc localhost -l 1234 > /dev/null\r\n}}}\r\n\r\nOn another shell, compile the following program and run it:\r\n\r\n{{{\r\n% ghc -threaded sock.hs\r\n% ./sock localhost 1234\r\nreceiver: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ViewPatterns #-}\r\n\r\nimport Control.Applicative -- GHC 7.8 compatibility\r\nimport Control.Concurrent\r\nimport qualified Control.Exception as Ex\r\nimport Control.Monad\r\nimport qualified Data.ByteString.Char8 as S\r\nimport Network.Socket\r\nimport qualified Network.Socket.ByteString as Sock\r\nimport Network.BSD (getHostByName, hostAddresses)\r\nimport System.Environment\r\nimport System.Mem\r\n\r\nmain :: IO ()\r\nmain = do\r\n [host, read -> fromInteger -> port] <- getArgs\r\n sock <- connectTo host port\r\n forkVerbose \"sender\" $ forever $ do\r\n _ <- Sock.send sock $ S.replicate 40000 '0'\r\n return ()\r\n forkVerbose \"receiver\" $ forever $ do\r\n dat <- Sock.recv sock 2048\r\n putStrLn $ \"received: \" ++ show dat\r\n forever $ do\r\n threadDelay 1000000\r\n performGC\r\n\r\nforkVerbose :: String -> IO () -> IO ()\r\nforkVerbose name act = void $ forkIO $ do act; msg \"exiting normally\"\r\n `Ex.catch` \\e -> msg $ show (e :: Ex.SomeException)\r\n where \r\n msg s = putStrLn $ name ++ \": \" ++ s\r\n\r\nconnectTo :: HostName -> PortNumber -> IO Socket\r\nconnectTo hostName port = do\r\n addr <- SockAddrInet port <$> lookupHost hostName\r\n sock <- socket AF_INET Stream 0\r\n connect sock addr\r\n return sock\r\n\r\nlookupHost :: String -> IO HostAddress\r\nlookupHost name = do\r\n hostInfo <- getHostByName name\r\n case hostAddresses hostInfo of\r\n [] -> error (\"Invalid host name: \" ++ name)\r\n (a:_) -> return a\r\n}}}\r\n\r\nGHC 7.8.3 doesn't have this problem.\r\n\r\nI suspect that this is a regression in the event manager. When there is an event, `GHC.Event.Manager.onFdEvent` seems to remove all callbacks associated to the `fd`, whether or not they match the current event. In the program above, the callback for `recv` may be removed permanently when the socket becomes ready for `send`ing, causing the \"receiver\" thread to deadlock.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10368STM test failing on Armhf/Linux2019-07-07T18:36:23ZerikdSTM test failing on Armhf/LinuxDuring validation on armhf/linux, I found that test T7815 had failed.
Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like:
```
for x in ...During validation on armhf/linux, I found that test T7815 had failed.
Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like:
```
for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo $? ; done
```
one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 times.
The two boards are:
- Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU.
- Radxa Rock with a Rockchip RK3199 CPU.
The ifc6540 is the one that fails.
\@fryguybob suggests that this is actually a bug in the STM implementation that breaks on Arm because of Arm's weaker memory consistency model.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10332AArch64 : divbyzero test fails2019-12-26T22:33:39ZerikdAArch64 : divbyzero test failsOn AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is:
```
main :: IO ()
main = print (5 `divInt` 0)
```
just prints "0" and exits with a zero status code.
From the "ARMv8 Instriction Set Overview" document I found ...On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is:
```
main :: IO ()
main = print (5 `divInt` 0)
```
just prints "0" and exits with a zero status code.
From the "ARMv8 Instriction Set Overview" document I found (wasn't able to find anything more recent):
https://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-102-1-229511/ARM.Reference_Manual.pdf
Section 3.6 says "There is no hardware check for “divide by zero”, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register."
Looks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"AArch64 : divbyzero test fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is:\r\n\r\n{{{\r\nmain :: IO ()\r\nmain = print (5 `divInt` 0)\r\n}}}\r\n\r\njust prints \"0\" and exits with a zero status code.\r\n\r\nFrom the \"ARMv8 Instriction Set Overview\" document I found (wasn't able to find anything more recent):\r\n\r\nhttps://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-102-1-229511/ARM.Reference_Manual.pdf\r\n\r\nSection 3.6 says \"There is no hardware check for “divide by zero”, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register.\"\r\n\r\nLooks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/10317Event manager: Multishot registrations only fire once2019-07-07T18:36:36ZBen GamariEvent manager: Multishot registrations only fire onceSince D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.
Unfortunately the implementation drops the registration af...Since D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.
Unfortunately the implementation drops the registration after it fires, resulting in only one callback invocation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Event manager: Multishot registrations only fire once","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Since D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.\r\n\r\nUnfortunately the implementation drops the registration after it fires, resulting in only one callback invocation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10245panic in new integer switch logic with "out-of-range" literals2019-07-07T18:36:55Zrwbartonpanic in new integer switch logic with "out-of-range" literalsCompiling this module
```
module D (f) where
f :: Int -> String
f n = case n of
0x8000000000000000 -> "yes"
_ -> "no"
```
crashes with the error
```
[1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o )
ghc-stage1: panic! (t...Compiling this module
```
module D (f) where
f :: Int -> String
f n = case n of
0x8000000000000000 -> "yes"
_ -> "no"
```
crashes with the error
```
[1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o )
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.11.20150403 for x86_64-unknown-linux):
Map.findMin: empty map has no minimal element
```
The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals.
The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | CompileTimeCrash |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nomeata, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic in new integer switch logic with \"out-of-range\" literals","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nomeata","simonmar"],"type":"Bug","description":"Compiling this module\r\n{{{\r\nmodule D (f) where\r\nf :: Int -> String\r\nf n = case n of\r\n 0x8000000000000000 -> \"yes\"\r\n _ -> \"no\"\r\n}}}\r\ncrashes with the error\r\n{{{\r\n[1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o )\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150403 for x86_64-unknown-linux):\r\n\tMap.findMin: empty map has no minimal element\r\n}}}\r\nThe constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals.\r\n\r\nThe bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does.","type_of_failure":"CompileTimeCrash","blocking":[]} -->8.2.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/10241BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely2019-07-07T18:36:56ZasukamiraiBlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitelyBlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely.
```hs
module Main where
import qualified Control.Concurrent.MVar as MV
import qualified Control.Conc...BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely.
```hs
module Main where
import qualified Control.Concurrent.MVar as MV
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
-- call this thread "threadA"
mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ())
mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ())
_ <- CC.forkIO $ do
-- call this thread "threadB"
MV.takeMVar mvar1 `E.catch` errorHandler1
putStrLn "after error catch"
CC.threadDelay 1000000
MV.putMVar mvar2 ()
putStrLn "after putMVar"
MV.readMVar mvar2 `E.catch` errorHandler2
putStrLn "after readMVar"
CC.threadDelay 5000000
where
errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e
```
Save above as "mvar.hs" and run by ghc as below.
```
> runhaskell mvar.hs
errorHandler1 : thread blocked indefinitely in an MVar operation
errorHandler2 : thread blocked indefinitely in an MVar operation
after error catch
after readMVar
after putMVar
```
BlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and "threadB" can continue to put the value to mvar2. It means that "threadA" can wait for the value of mvar2 and it is not blocked indefinately.
However, BlockedIndefinitelyOnMVar is thrown for mvar2 on "threadA" before "threadB" puts value to the mvar2. I think it is incorrect.
----
I tested another case that adding "CC.threadDelay 10000000" before "readMVar" as below.
```hs
module Main where
import qualified Control.Concurrent.MVar as MV
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
-- call this thread "threadA"
mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ())
mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ())
_ <- CC.forkIO $ do
-- call this thread "threadB"
MV.takeMVar mvar1 `E.catch` errorHandler1
putStrLn "after error catch"
CC.threadDelay 1000000
MV.putMVar mvar2 ()
putStrLn "after putMVar"
CC.threadDelay 10000000 -- <-- this line is added
MV.readMVar mvar2 `E.catch` errorHandler2
putStrLn "after readMVar"
CC.threadDelay 5000000
where
errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e
```
And it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2).
```
> runhaskell mvar.hs
errorHandler1 : thread blocked indefinitely in an MVar operation
after error catch
after putMVar
after readMVar
```
----
I found this behavior is same on STM / BlockedIndefinitelyOnSTM.
```hs
module Main where
import qualified Control.Concurrent.STM as STM
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
tmv1 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ())
tmv2 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ())
_ <- CC.forkIO $ do
STM.atomically (STM.takeTMVar tmv1) `E.catch` errorHandler1
putStrLn "after error catch"
CC.threadDelay 1000000
STM.atomically $ STM.putTMVar tmv2 ()
putStrLn "after putTMVar"
STM.atomically (STM.readTMVar tmv2) `E.catch` errorHandler2
putStrLn "after readTMVar"
CC.threadDelay 5000000
where
errorHandler1 :: E.BlockedIndefinitelyOnSTM -> IO ()
errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO ()
errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e
```
```
> runhaskell stm.hs
errorHandler1 : thread blocked indefinitely in an STM transaction
errorHandler2 : thread blocked indefinitely in an STM transaction
after error catch
after readTMVar
after putTMVar
```
----
I tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2).
ghc7.8.3 on Windows7
ghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7
ghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7
ghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7
Similar report #8804 found but not the same.
(In this case, the reference to the MVar is not weak)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely.\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Control.Concurrent.MVar as MV\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Exception as E\r\n\r\nmain :: IO ()\r\nmain = do\r\n -- call this thread \"threadA\"\r\n mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ())\r\n mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ())\r\n _ <- CC.forkIO $ do\r\n -- call this thread \"threadB\"\r\n MV.takeMVar mvar1 `E.catch` errorHandler1\r\n putStrLn \"after error catch\"\r\n CC.threadDelay 1000000\r\n MV.putMVar mvar2 ()\r\n putStrLn \"after putMVar\"\r\n MV.readMVar mvar2 `E.catch` errorHandler2\r\n putStrLn \"after readMVar\"\r\n CC.threadDelay 5000000\r\n where\r\n errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO ()\r\n errorHandler1 e = putStrLn $ \"errorHandler1 : \" ++ show e\r\n errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()\r\n errorHandler2 e = putStrLn $ \"errorHandler2 : \" ++ show e\r\n}}}\r\n\r\nSave above as \"mvar.hs\" and run by ghc as below.\r\n\r\n{{{\r\n> runhaskell mvar.hs\r\nerrorHandler1 : thread blocked indefinitely in an MVar operation\r\nerrorHandler2 : thread blocked indefinitely in an MVar operation\r\nafter error catch\r\nafter readMVar\r\nafter putMVar\r\n}}}\r\n\r\nBlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and \"threadB\" can continue to put the value to mvar2. It means that \"threadA\" can wait for the value of mvar2 and it is not blocked indefinately.\r\nHowever, BlockedIndefinitelyOnMVar is thrown for mvar2 on \"threadA\" before \"threadB\" puts value to the mvar2. I think it is incorrect.\r\n\r\n----\r\n\r\nI tested another case that adding \"CC.threadDelay 10000000\" before \"readMVar\" as below.\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Control.Concurrent.MVar as MV\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Exception as E\r\n\r\nmain :: IO ()\r\nmain = do\r\n -- call this thread \"threadA\"\r\n mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ())\r\n mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ())\r\n _ <- CC.forkIO $ do\r\n -- call this thread \"threadB\"\r\n MV.takeMVar mvar1 `E.catch` errorHandler1\r\n putStrLn \"after error catch\"\r\n CC.threadDelay 1000000\r\n MV.putMVar mvar2 ()\r\n putStrLn \"after putMVar\"\r\n CC.threadDelay 10000000 -- <-- this line is added\r\n MV.readMVar mvar2 `E.catch` errorHandler2\r\n putStrLn \"after readMVar\"\r\n CC.threadDelay 5000000\r\n where\r\n errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO ()\r\n errorHandler1 e = putStrLn $ \"errorHandler1 : \" ++ show e\r\n errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()\r\n errorHandler2 e = putStrLn $ \"errorHandler2 : \" ++ show e\r\n}}}\r\n\r\nAnd it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2).\r\n\r\n{{{\r\n> runhaskell mvar.hs\r\nerrorHandler1 : thread blocked indefinitely in an MVar operation\r\nafter error catch\r\nafter putMVar\r\nafter readMVar\r\n}}}\r\n\r\n----\r\n\r\nI found this behavior is same on STM / BlockedIndefinitelyOnSTM.\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Control.Concurrent.STM as STM\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Exception as E\r\n\r\nmain :: IO ()\r\nmain = do\r\n tmv1 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ())\r\n tmv2 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ())\r\n _ <- CC.forkIO $ do\r\n STM.atomically (STM.takeTMVar tmv1) `E.catch` errorHandler1\r\n putStrLn \"after error catch\"\r\n CC.threadDelay 1000000\r\n STM.atomically $ STM.putTMVar tmv2 ()\r\n putStrLn \"after putTMVar\"\r\n STM.atomically (STM.readTMVar tmv2) `E.catch` errorHandler2\r\n putStrLn \"after readTMVar\"\r\n CC.threadDelay 5000000\r\n where\r\n errorHandler1 :: E.BlockedIndefinitelyOnSTM -> IO ()\r\n errorHandler1 e = putStrLn $ \"errorHandler1 : \" ++ show e\r\n errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO ()\r\n errorHandler2 e = putStrLn $ \"errorHandler2 : \" ++ show e\r\n}}}\r\n\r\n{{{\r\n> runhaskell stm.hs\r\nerrorHandler1 : thread blocked indefinitely in an STM transaction\r\nerrorHandler2 : thread blocked indefinitely in an STM transaction\r\nafter error catch\r\nafter readTMVar\r\nafter putTMVar\r\n}}}\r\n\r\n----\r\n\r\nI tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2).\r\n\r\nghc7.8.3 on Windows7\r\nghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7\r\nghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7\r\nghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7\r\n\r\nSimilar report https://ghc.haskell.org/trac/ghc/ticket/8804 found but not the same.\r\n(In this case, the reference to the MVar is not weak)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10236DWARF unwind info is broken2019-07-07T18:36:57ZthoughtpoliceDWARF unwind info is brokenAs reported by `bitonic` and `petermw` on `#ghc` (April 2nd):
```
07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using
<https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I ge...As reported by `bitonic` and `petermw` on `#ghc` (April 2nd):
```
07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using
<https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is
`Backtrace stopped: previous frame identical to this frame (corrupt stack?)`
07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if
I'm not sure it's even necessary
07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary
I'm generating is sane?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | scpmw |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DWARF unwind info is broken","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["dwarf"],"differentials":[],"test_case":"","architecture":"","cc":["scpmw"],"type":"Bug","description":"As reported by `bitonic` and `petermw` on `#ghc` (April 2nd):\r\n\r\n{{{\r\n07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using \r\n <https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is \r\n `Backtrace stopped: previous frame identical to this frame (corrupt stack?)`\r\n07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if \r\n I'm not sure it's even necessary\r\n07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary \r\n I'm generating is sane?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10231TMVar - fmap - orElse clashes in ghc 7.8.42019-07-07T18:36:59ZranTMVar - fmap - orElse clashes in ghc 7.8.4Attached is a tar archive with minimal reproducible example.
The problem is that after orElse success I get wrong constructor: I should have timer tick but get reset instead. That is, expected output is
```
timer thread
timer tick
time...Attached is a tar archive with minimal reproducible example.
The problem is that after orElse success I get wrong constructor: I should have timer tick but get reset instead. That is, expected output is
```
timer thread
timer tick
timer thread
timer tick
...
```
but I get
```
timer thread
reset
timer thread
reset
...
```
The strange thing is that the problem presents, first, only when the binary is built by cabal (checked only inside sandbox):
```
$ cabal sandbox init
...
$ cabal configure
Resolving dependencies...
Configuring mvk-0.1.0.0...
cabal: At least the following dependencies are missing:
stm ==2.4.4
$ cabal install --dependencies-only
...
$ cabal build
```
When I run
```
cabal exec -- ghc --make mvk.hs
```
the resulting binary doesn't show the problem.
Also, problem disappears if I:
- either comment start of the (long-sleeping) reset thread at all;
- or change content type of one of TMVars to, say, Bool
But if I change type of content for both to, say, Bool, the problem presents. Furthermore, if with Bool content type I put False in timer thread and True in reset thread (and derive Show and output received value) I get
```
timer thread
received Reset False
reset
...
```
That is, underlying Bool is right, but fmapped constructor is wrong.
The problem was absent in Debian Wheezy's ghc 7.4.1 (not sure about STM version).
Reproduced both in
- Debian Jessie on x86_64 with GHC 7.8.4 binary from official site and cabal-install 1.20.0.3 from deb.haskell.org
- Debian Wheezy on x86 with GHC 7.8.3 binary from deb.haskell.org and cabal-install 1.20.0.3 built by GHC from dist.
In all cases used cabal.config from Stackage's lts-1.4 (included in the attached archive)
Output from cabal build -v:
```
Skipping add-source deps check...
Using a sandbox located at
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox
The sandbox was created after the package was already configured.
Re-configuring with most recently used options. If this fails, please run
configure manually.
Using a sandbox located at
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox
'/opt/ghc/7.8.4/bin/ghc' '--numeric-version'
looking for tool ghc-pkg near compiler in /opt/ghc/7.8.4/bin
found ghc-pkg in /opt/ghc/7.8.4/bin/ghc-pkg
'/opt/ghc/7.8.4/bin/ghc-pkg' '--version'
'/opt/ghc/7.8.4/bin/ghc' '--supported-languages'
'/opt/ghc/7.8.4/bin/ghc' '--info'
Reading available packages...
Reading available packages...
Choosing modular solver.
Resolving dependencies...
Configuring mvk-0.1.0.0...
Dependency base ==4.7.0.2: using base-4.7.0.2
Dependency stm ==2.4.4: using stm-2.4.4
Using Cabal-1.20.0.0 compiled by ghc-7.4
Using compiler: ghc-7.8.4
Using install prefix:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox
Binaries installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/bin
Libraries installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0
Private binaries installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/libexec
Data files installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0
Documentation installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/doc/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0
Configuration files installed in:
/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/etc
Using alex version 3.1.3 found on system at: /usr/bin/alex
Using ar found on system at: /usr/bin/ar
No c2hs found
No cpphs found
No ffihugs found
Using gcc version 4.9.2 found on system at: /usr/bin/gcc
Using ghc version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc
Using ghc-pkg version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc-pkg
No greencard found
Using haddock version 2.14.3 found on system at: /opt/ghc/7.8.4/bin/haddock
Using happy version 1.19.4 found on system at: /usr/bin/happy
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.67 found on system at: /opt/ghc/7.8.4/bin/hpc
Using hsc2hs version 0.67 found on system at: /opt/ghc/7.8.4/bin/hsc2hs
Using hscolour version 1.20 found on system at: /usr/bin/HsColour
No hugs found
No jhc found
Using ld found on system at: /usr/bin/ld
No lhc found
No lhc-pkg found
No nhc98 found
Using pkg-config version 0.28 found on system at: /usr/bin/pkg-config
Using strip found on system at: /usr/bin/strip
Using tar found on system at: /bin/tar
No uhc found
Component build order: executable 'mvk'
creating dist/build
creating dist/build/autogen
Building mvk-0.1.0.0...
Preprocessing executable 'mvk' for mvk-0.1.0.0...
Building executable mvk...
creating dist/build/mvk
creating dist/build/mvk/mvk-tmp
/opt/ghc/7.8.4/bin/ghc --make -no-link -fbuilding-cabal-package -O -j4 -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk/mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk/mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -no-user-package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -Wall
Linking...
/opt/ghc/7.8.4/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk/mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk/mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -no-user-package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -o dist/build/mvk/mvk -Wall
Linking dist/build/mvk/mvk ...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TMVar - fmap - orElse clashes in ghc 7.8.4","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached is a tar archive with minimal reproducible example.\r\n\r\nThe problem is that after orElse success I get wrong constructor: I should have timer tick but get reset instead. That is, expected output is\r\n\r\n{{{\r\ntimer thread\r\ntimer tick\r\ntimer thread\r\ntimer tick\r\n...\r\n}}}\r\n\r\nbut I get\r\n\r\n{{{\r\ntimer thread\r\nreset\r\ntimer thread\r\nreset\r\n...\r\n}}}\r\n\r\nThe strange thing is that the problem presents, first, only when the binary is built by cabal (checked only inside sandbox):\r\n\r\n{{{\r\n$ cabal sandbox init\r\n...\r\n$ cabal configure\r\nResolving dependencies...\r\nConfiguring mvk-0.1.0.0...\r\ncabal: At least the following dependencies are missing:\r\nstm ==2.4.4\r\n$ cabal install --dependencies-only\r\n...\r\n$ cabal build\r\n}}}\r\n\r\nWhen I run\r\n\r\n{{{\r\ncabal exec -- ghc --make mvk.hs\r\n}}}\r\n\r\nthe resulting binary doesn't show the problem.\r\n\r\nAlso, problem disappears if I:\r\n\r\n* either comment start of the (long-sleeping) reset thread at all;\r\n* or change content type of one of TMVars to, say, Bool\r\n\r\nBut if I change type of content for both to, say, Bool, the problem presents. Furthermore, if with Bool content type I put False in timer thread and True in reset thread (and derive Show and output received value) I get\r\n\r\n{{{\r\ntimer thread\r\nreceived Reset False\r\nreset\r\n...\r\n}}}\r\n\r\nThat is, underlying Bool is right, but fmapped constructor is wrong.\r\n\r\nThe problem was absent in Debian Wheezy's ghc 7.4.1 (not sure about STM version).\r\n\r\nReproduced both in\r\n\r\n* Debian Jessie on x86_64 with GHC 7.8.4 binary from official site and cabal-install 1.20.0.3 from deb.haskell.org\r\n* Debian Wheezy on x86 with GHC 7.8.3 binary from deb.haskell.org and cabal-install 1.20.0.3 built by GHC from dist.\r\n\r\nIn all cases used cabal.config from Stackage's lts-1.4 (included in the attached archive)\r\n\r\nOutput from cabal build -v:\r\n\r\n{{{\r\nSkipping add-source deps check...\r\nUsing a sandbox located at\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox\r\nThe sandbox was created after the package was already configured.\r\nRe-configuring with most recently used options. If this fails, please run\r\nconfigure manually.\r\nUsing a sandbox located at\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox\r\n'/opt/ghc/7.8.4/bin/ghc' '--numeric-version'\r\nlooking for tool ghc-pkg near compiler in /opt/ghc/7.8.4/bin\r\nfound ghc-pkg in /opt/ghc/7.8.4/bin/ghc-pkg\r\n'/opt/ghc/7.8.4/bin/ghc-pkg' '--version'\r\n'/opt/ghc/7.8.4/bin/ghc' '--supported-languages'\r\n'/opt/ghc/7.8.4/bin/ghc' '--info'\r\nReading available packages...\r\nReading available packages...\r\nChoosing modular solver.\r\nResolving dependencies...\r\nConfiguring mvk-0.1.0.0...\r\nDependency base ==4.7.0.2: using base-4.7.0.2\r\nDependency stm ==2.4.4: using stm-2.4.4\r\nUsing Cabal-1.20.0.0 compiled by ghc-7.4\r\nUsing compiler: ghc-7.8.4\r\nUsing install prefix:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox\r\nBinaries installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/bin\r\nLibraries installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0\r\nPrivate binaries installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/libexec\r\nData files installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0\r\nDocumentation installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/doc/x86_64-linux-ghc-7.8.4/mvk-0.1.0.0\r\nConfiguration files installed in:\r\n/.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/etc\r\nUsing alex version 3.1.3 found on system at: /usr/bin/alex\r\nUsing ar found on system at: /usr/bin/ar\r\nNo c2hs found\r\nNo cpphs found\r\nNo ffihugs found\r\nUsing gcc version 4.9.2 found on system at: /usr/bin/gcc\r\nUsing ghc version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc\r\nUsing ghc-pkg version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc-pkg\r\nNo greencard found\r\nUsing haddock version 2.14.3 found on system at: /opt/ghc/7.8.4/bin/haddock\r\nUsing happy version 1.19.4 found on system at: /usr/bin/happy\r\nUsing haskell-suite found on system at: haskell-suite-dummy-location\r\nUsing haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location\r\nNo hmake found\r\nUsing hpc version 0.67 found on system at: /opt/ghc/7.8.4/bin/hpc\r\nUsing hsc2hs version 0.67 found on system at: /opt/ghc/7.8.4/bin/hsc2hs\r\nUsing hscolour version 1.20 found on system at: /usr/bin/HsColour\r\nNo hugs found\r\nNo jhc found\r\nUsing ld found on system at: /usr/bin/ld\r\nNo lhc found\r\nNo lhc-pkg found\r\nNo nhc98 found\r\nUsing pkg-config version 0.28 found on system at: /usr/bin/pkg-config\r\nUsing strip found on system at: /usr/bin/strip\r\nUsing tar found on system at: /bin/tar\r\nNo uhc found\r\nComponent build order: executable 'mvk'\r\ncreating dist/build\r\ncreating dist/build/autogen\r\nBuilding mvk-0.1.0.0...\r\nPreprocessing executable 'mvk' for mvk-0.1.0.0...\r\nBuilding executable mvk...\r\ncreating dist/build/mvk\r\ncreating dist/build/mvk/mvk-tmp\r\n/opt/ghc/7.8.4/bin/ghc --make -no-link -fbuilding-cabal-package -O -j4 -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk/mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk/mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -no-user-package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -Wall\r\nLinking...\r\n/opt/ghc/7.8.4/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk/mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk/mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -no-user-package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -o dist/build/mvk/mvk -Wall\r\nLinking dist/build/mvk/mvk ...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10215Optimizer has bugs regarding handling of -0.02019-07-07T18:37:03ZLevent ErkökOptimizer has bugs regarding handling of -0.0This is most likely related to #9238
Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this...This is most likely related to #9238
Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case.
I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well.
For the following program:
```hs
testF :: Float -> Bool
testF x = x == 0 && not (isNegativeZero x)
testD :: Double -> Bool
testD x = x == 0 && not (isNegativeZero x)
main :: IO ()
main = do print $ testF (-0.0)
print $ testD (-0.0)
```
If I compile with no optimizations, then I get the correct answers:
```
$ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a
[1 of 1] Compiling Main ( a.hs, a.o )
Linking a ...
False
False
```
But if I turn optimizations on, then I get:
```
$ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a
[1 of 1] Compiling Main ( a.hs, a.o )
Linking a ...
True
True
```
which is just plain wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimizer has bugs regarding handling of -0.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238\r\n\r\nPerhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case.\r\n\r\nI observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well.\r\nFor the following program:\r\n\r\n{{{#!hs\r\ntestF :: Float -> Bool\r\ntestF x = x == 0 && not (isNegativeZero x)\r\n\r\ntestD :: Double -> Bool\r\ntestD x = x == 0 && not (isNegativeZero x)\r\n\r\nmain :: IO ()\r\nmain = do print $ testF (-0.0)\r\n print $ testD (-0.0)\r\n}}}\r\n\r\nIf I compile with no optimizations, then I get the correct answers:\r\n{{{\r\n$ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a\r\n[1 of 1] Compiling Main ( a.hs, a.o )\r\nLinking a ...\r\nFalse\r\nFalse\r\n}}}\r\n\r\nBut if I turn optimizations on, then I get:\r\n{{{\r\n$ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a\r\n[1 of 1] Compiling Main ( a.hs, a.o )\r\nLinking a ...\r\nTrue\r\nTrue\r\n}}}\r\n\r\nwhich is just plain wrong. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10205On Windows ghc-pkg always reports cache out of date2019-07-07T18:37:05ZHoward B. GoldenOn Windows ghc-pkg always reports cache out of dateWhen I ran `ghc-pkg list` on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the pack...When I ran `ghc-pkg list` on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below.
Original error:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg check
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
```
Checking timestamps:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list
Timestamp 2015-03-27 21:18:29.5247984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa
ckage.cache
Timestamp 2015-03-27 21:18:29.5277984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N
EWER than cache)
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
Timestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
Timestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c
ache)
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
```
Recaching as instructed:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --user
[snip...]
modifying: Just "C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"
flag db stack: ["C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"]
writing cache C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --global
[snip...]
modifying: Just "C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"
flag db stack: ["C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"]
writing cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
```
Looking at timestamps after recaching:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list
Timestamp 2015-03-27 21:21:50.3341984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa
ckage.cache
Timestamp 2015-03-27 21:21:50.3371984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N
EWER than cache)
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
Timestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
Timestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c
ache)
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
C:\Users\hgolden\AppData\Roaming>
```
Timestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"On Windows ghc-pkg always reports cache out of date","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"When I ran {{{ghc-pkg list}}} on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below.\r\n\r\nOriginal error:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg check\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\n}}}\r\nChecking timestamps:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 list\r\nTimestamp 2015-03-27 21:18:29.5247984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\pa\r\nckage.cache\r\nTimestamp 2015-03-27 21:18:29.5277984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d (N\r\nEWER than cache)\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\nTimestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nTimestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d (NEWER than c\r\nache)\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\n}}}\r\nRecaching as instructed:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 recache --user\r\n[snip...]\r\nmodifying: Just \"C:\\\\Users\\\\hgolden\\\\AppData\\\\Roaming\\\\ghc\\\\i386-mingw32-7.10.1\\\\package.conf.d\"\r\nflag db stack: [\"C:\\\\Users\\\\hgolden\\\\AppData\\\\Roaming\\\\ghc\\\\i386-mingw32-7.10.1\\\\package.conf.d\"]\r\nwriting cache C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 recache --global\r\n[snip...]\r\nmodifying: Just \"C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\\\lib\\\\package.conf.d\"\r\nflag db stack: [\"C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\\\lib\\\\package.conf.d\"]\r\nwriting cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\n}}}\r\nLooking at timestamps after recaching:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 list\r\nTimestamp 2015-03-27 21:21:50.3341984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\pa\r\nckage.cache\r\nTimestamp 2015-03-27 21:21:50.3371984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d (N\r\nEWER than cache)\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\nTimestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nTimestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d (NEWER than c\r\nache)\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\nC:\\Users\\hgolden\\AppData\\Roaming>\r\n}}}\r\nTimestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2