GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:53:13Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5865threadDelay is disrupted by system clock changes2019-07-07T18:53:13ZjoeyadamsthreadDelay is disrupted by system clock changesthreadDelay is sensitive to changes to the system clock. Two behaviors are observed:
- When the system clock is moved forward, threadDelay will timeout prematurely, because it thinks that amount of time elapsed.
- When the system clock ...threadDelay is sensitive to changes to the system clock. Two behaviors are observed:
- When the system clock is moved forward, threadDelay will timeout prematurely, because it thinks that amount of time elapsed.
- When the system clock is moved backward, threadDelay will take longer to complete, because it's waiting for the system clock to catch up.
Whether these behaviors are present depends on both the operating system and the use of -threaded. Here are the configurations I tested:
- ghc-7.4.1 Linux 64-bit: Disrupted by both forward and backward clock changes
- ghc-7.4.1 Linux 64-bit, **-threaded**: Disrupted only by backward clock changes
- ghc-7.2.2 Windows 32-bit: Not disrupted by clock changes (behaves correctly)
- ghc-7.2.2 Windows 32-bit, **-threaded**: Disrupted only by backward clock changes
To reproduce the problem, first compile the attached program. It uses System.Posix.Clock from the "clock" package to get the time, unaffected by system clock changes. Then run it. It will produce output like this:
```
0: 0s
1: 10s
```
Set the system clock forward by a minute. On Linux without -threaded, it will print something like this:
```
5: 50s
6: 52s
```
6 is printed 2 seconds after 5, because threadDelay didn't wait a full 10 seconds like it should have.
Now set the system clock backward by a minute. On Windows with -threaded, or on Linux with or without -threaded, it will print something like this:
```
3: 30s
4: 101s
```
4 is printed over a minute after 3, because threadDelay waited for the system clock to recover the time subtracted by changing the time.
For convenience, here's a way to fix the system clock on Linux after fiddling around with it:
```
sudo ntpdate pool.ntp.org
```
Digging through the source, each configuration seems to boil down to the following system calls:
- Linux: gettimeofday (via getourtimeofday in posix/Itimer.c)
- Linux, **-threaded**: gettimeofday, epoll_wait
- Windows: [Sleep](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspx)
- Windows, **-threaded**: [GetSystemTimeAsFileTime](http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx), [WaitForSingleObject](http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032%28v=vs.85%29.aspx)
Perhaps the calls to gettimeofday and GetSystemTimeAsFileTime should be replaced with monotonic time functions (i.e. ones not affected by system clock changes):
- Linux, FreeBSD: http://stackoverflow.com/q/211055/149391
- Mac OS X: http://stackoverflow.com/a/6725161/149391
- Windows: http://stackoverflow.com/q/211257/149391
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay is disrupted by system clock changes","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"threadDelay is sensitive to changes to the system clock. Two behaviors are observed:\r\n\r\n * When the system clock is moved forward, threadDelay will timeout prematurely, because it thinks that amount of time elapsed.\r\n\r\n * When the system clock is moved backward, threadDelay will take longer to complete, because it's waiting for the system clock to catch up.\r\n\r\nWhether these behaviors are present depends on both the operating system and the use of -threaded. Here are the configurations I tested:\r\n\r\n * ghc-7.4.1 Linux 64-bit: Disrupted by both forward and backward clock changes\r\n\r\n * ghc-7.4.1 Linux 64-bit, '''-threaded''': Disrupted only by backward clock changes\r\n\r\n * ghc-7.2.2 Windows 32-bit: Not disrupted by clock changes (behaves correctly)\r\n\r\n * ghc-7.2.2 Windows 32-bit, '''-threaded''': Disrupted only by backward clock changes\r\n\r\nTo reproduce the problem, first compile the attached program. It uses System.Posix.Clock from the \"clock\" package to get the time, unaffected by system clock changes. Then run it. It will produce output like this:\r\n\r\n{{{\r\n0: 0s\r\n1: 10s\r\n}}}\r\n\r\nSet the system clock forward by a minute. On Linux without -threaded, it will print something like this:\r\n\r\n{{{\r\n5: 50s\r\n6: 52s\r\n}}}\r\n\r\n6 is printed 2 seconds after 5, because threadDelay didn't wait a full 10 seconds like it should have.\r\n\r\nNow set the system clock backward by a minute. On Windows with -threaded, or on Linux with or without -threaded, it will print something like this:\r\n\r\n{{{\r\n3: 30s\r\n4: 101s\r\n}}}\r\n\r\n4 is printed over a minute after 3, because threadDelay waited for the system clock to recover the time subtracted by changing the time.\r\n\r\nFor convenience, here's a way to fix the system clock on Linux after fiddling around with it:\r\n\r\n{{{\r\nsudo ntpdate pool.ntp.org\r\n}}}\r\n\r\nDigging through the source, each configuration seems to boil down to the following system calls:\r\n\r\n * Linux: gettimeofday (via getourtimeofday in posix/Itimer.c)\r\n\r\n * Linux, '''-threaded''': gettimeofday, epoll_wait\r\n\r\n * Windows: [http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspx Sleep]\r\n\r\n * Windows, '''-threaded''': [http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx GetSystemTimeAsFileTime], [http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032%28v=vs.85%29.aspx WaitForSingleObject]\r\n\r\nPerhaps the calls to gettimeofday and GetSystemTimeAsFileTime should be replaced with monotonic time functions (i.e. ones not affected by system clock changes):\r\n\r\n * Linux, FreeBSD: http://stackoverflow.com/q/211055/149391\r\n\r\n * Mac OS X: http://stackoverflow.com/a/6725161/149391\r\n\r\n * Windows: http://stackoverflow.com/q/211257/149391","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/7325threadDelay mistreats minBound and maxBound in some configurations2019-07-07T18:50:14ZjoeyadamsthreadDelay mistreats minBound and maxBound in some configurationsthreadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([as seen in the async package](http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async....threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([as seen in the async package](http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently)):
```
forever (threadDelay maxBound)
```
On Linux (Ubuntu 10.04 64-bit) without -threaded, `threadDelay maxBound` returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:
```
import Control.Concurrent
import Control.Monad
main = forM_ [6244222868950683224..] $ \i -> do
print i
threadDelay i
```
threadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:
```
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
```
The bug usually appears, but if I run it like this:
```
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs
./threadDelay-maxBound
```
The bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.
On Windows without -threaded, `threadDelay maxBound` seems to work, but `threadDelay minBound` blocks rather than returning immediately.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay mistreats minBound and maxBound in some configurations","status":"New","operating_system":"Unknown/Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently as seen in the async package]):\r\n\r\n{{{\r\nforever (threadDelay maxBound)\r\n}}}\r\n\r\nOn Linux (Ubuntu 10.04 64-bit) without -threaded, {{{threadDelay maxBound}}} returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Monad\r\n\r\nmain = forM_ [6244222868950683224..] $ \\i -> do\r\n print i\r\n threadDelay i\r\n}}}\r\n\r\nthreadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:\r\n\r\n{{{\r\nghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound\r\n}}}\r\n\r\nThe bug usually appears, but if I run it like this:\r\n\r\n{{{\r\nghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs\r\n./threadDelay-maxBound\r\n}}}\r\n\r\nThe bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.\r\n\r\nOn Windows without -threaded, {{{threadDelay maxBound}}} seems to work, but {{{threadDelay minBound}}} blocks rather than returning immediately.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/9333Thread status decoded wrong in base library2019-07-07T18:40:51ZJost BertholdThread status decoded wrong in base libraryKyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/C...Kyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483) decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.
The constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, ezyang, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Thread status decoded wrong in base library","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","ezyang","hvr","simonmar"],"type":"Bug","description":"Kyle Van Berendonck <kvanberendonck@gmail.com> in [http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html a message on ghc-devs] pointed to [https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 base/GHC/Conc/Sync.lhs] decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.\r\n\r\nThe constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Jost BertholdJost Bertholdhttps://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/19771TH recompilation check is defeated by packages2021-06-08T19:30:57ZMatthew PickeringTH recompilation check is defeated by packagesIt's possible to defeat the recompilation checker by using and then modifying a TH definition from another package.
Reproducer: https://github.com/mpickering/special-fiesta
In the example there are two packages. Package `p` defines a l...It's possible to defeat the recompilation checker by using and then modifying a TH definition from another package.
Reproducer: https://github.com/mpickering/special-fiesta
In the example there are two packages. Package `p` defines a library
```
module Lib where
{-# NOINLINE p #-}
p = [| 0 |]
```
which is then used in package `q`:
```
module Main where
import Lib
main = print $(p)
```
Running the executable prints `0` initially.
Then modifying the library `p`,
```
module Lib where
p = [| 1 |]
```
when the executable is rerun the result should be printing `1`, but it still prints `0`.
The recompilation check fails because the ABI for `Lib` didn't change, and so GHC concluded that it didn't need to recompile `Main` again.
The logic for computing stable modules only considers stability for home package modules when it should also consider whether the object files for dependencies have changed.
A correct fix is to take the hash of all the object files in the transitive dependencies of a module (such as is already done for plugins)Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/5653"throw" in IO monad is incorrectly optimized away2019-07-07T18:54:11Zquark"throw" in IO monad is incorrectly optimized awayIn this example program, if I set things up just right, GHC will incorrectly execute a function on the IO monad. I can get GHC to execute it properly by removing an unnecessary Id from the export list (!!), by removing some complexity in...In this example program, if I set things up just right, GHC will incorrectly execute a function on the IO monad. I can get GHC to execute it properly by removing an unnecessary Id from the export list (!!), by removing some complexity in the function (removing if-stmts, for example), or by inserting a trace statement.
On Linux machines (both 32-bit and 64-bit): This bug occurs with GHC 6.12.3 and 6.12.1. It does not occur with 6.8.2 or with 7, but I do not know if this is because the bug was fixed or perhaps the bug is not triggered. Therefore, I'm attaching this example, so that you can identify the source of the bug, and then judge whether it still exists in GHC 7.
I have tested on Mac OS X with GHC 6.10.4 and the bug does not occur there.
In the attached tar-ball, just type "make" and it will build the executable "Main" from "Main.hs". This program calls an IO monad function in "Wrap.hs", which has several execution paths through it, but one path throws an error, using a function in "Error.hs" (and this is the path that "Main" stimulates). The other files are for data types used by "Wrap". I have attempted to reduce these files to only what is needed. Note that the "Id" type needs to use SpeedyString, or else the bug isn't triggered.
When you run "Main", you get this:
```
# ./Main
Num elements before (expect 1): 1
Num elements after (expect 1): 0
IF YOU SEE THIS MESSAGE, GHC HAS A BUG
```
In "addWrap", the first trace shows that the list "is" has one element. When we "concatMapM" over the list, it should still have one element. There is no branch that would produce zero elements, and yet that's what GHC did! If GHC had properly executed the monad statements, then the call to "err" would have thrown an error, looking like this:
```
# ./Main
Num elements before (expect 1): 1
Main: Normal user error
```
You can get GHC to produce this correct behavior in several ways. One is to uncomment (and thus add in) the trace statement right before the call to "err":
```
traceM("reached error")
```
Another way to get the correct behavior is to remove the export of "unsafeMessageExit" from "Error.hs"! How odd! That function is not used anywhere, but maybe it's existence adds more users of "throw" which changes GHC's use analysis or something?
And, of course, you can prevent the bug by simplifying the program in various ways. Removing some if-expressions or case-expressions from "Wrap" will do it. Note that even just leaving in if-expressions that have the same value in both arms (such as the definition of "r_ctxs") will trigger the bug!https://gitlab.haskell.org/ghc/ghc/-/issues/20451Ticky's ticker registration is racy2022-01-05T09:54:13ZBen GamariTicky's ticker registration is racyThe code generated for registration of ticky-ticky counters is currently racy. Specifically, `GHC.StgToCmm.Ticky.registerTickyCtr` adds its ticker to the `ticky_entry_ctrs` linked-list by performing a read-modify-write, which may race wi...The code generated for registration of ticky-ticky counters is currently racy. Specifically, `GHC.StgToCmm.Ticky.registerTickyCtr` adds its ticker to the `ticky_entry_ctrs` linked-list by performing a read-modify-write, which may race with other threads when compiling threaded code. This really ought to rather be an atomic exchange.Ben GamariBen Gamarihttps://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/4970time002 and time004 (ghci) test failures on OS X 64 bit2019-07-07T18:57:32Zgwright@antiope.comtime002 and time004 (ghci) test failures on OS X 64 bitThe `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0...The `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
*** Exception: Time.toClockTime: picoseconds out of range
*Main> main
Ok.
*Main>
```
If I modify the test to print the results of `getClockTime` and `toCalendarTime`, I see
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Sat Feb 19 10:12:35 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 35, ctPicosec = 112417000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
Ok.
*Main> main
Sat Feb 19 10:12:37 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 37, ctPicosec = 4295408225000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
*** Exception: Time.toClockTime: picoseconds out of range
*Main>
```
The `ctPicosec` field is too big.
The interesting thing is that if I dump the relocations for HSold-time-1.0.0.6.o, and grep for `ctPicosec`, I see
```
plumbbob-franklin> otool -rv HSold-time-1.0.0.6.o | grep ctPicosec
00023c5d False long True SUB False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info_dsp
00023c5d False long True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
00023c55 True long True SIGNED False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_closure
00001cf8 False quad True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
```
The first relocation is an `X86_64_RELOC_SUBTRACTOR`. This is probably being done incorrectly. (It may be distantly related to #4013, which also seems to be a subtractor relocation gone awry, but in that case of x86. The details of the x86 and x86_64 cases are quite different, but the original code for both cases is from the same author.)
After the patch that fixed #4867, there between five and seven test failures that only involve `ghci`. I'm uncertain about two because I've been building unthreaded to simplify debugging and two tests require threads. I suspect linker bugs in all these cases.
I've found a convenient list of x86_64 relocation examples at [http://developer.apple.com/library/mac/\#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html\#//apple_ref/doc/uid/TP40002528-SW1](http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528-SW1). I'll check the OS X 64 bit linker in its current state against these. Unfortunately, the list does not seem to be exhaustive. For instance, it doesn't contain the inter-section relocation that was at issue in #4867.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"time002 and time004 (ghci) test failures on OS X 64 bit","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:\r\n\r\n{{{\r\nplumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs\r\nGHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 1] Compiling Main ( time002.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nLoading package array-0.3.0.2 ... linking ... done.\r\nLoading package filepath-1.2.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.6 ... linking ... done.\r\nLoading package unix-2.4.1.0 ... linking ... done.\r\nLoading package directory-1.1.0.0 ... linking ... done.\r\nLoading package process-1.0.1.5 ... linking ... done.\r\nLoading package time-1.2.0.3 ... linking ... done.\r\nLoading package random-1.0.0.3 ... linking ... done.\r\nLoading package haskell98-1.1.0.1 ... linking ... done.\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\n*** Exception: Time.toClockTime: picoseconds out of range\r\n*Main> main\r\nOk.\r\n*Main> \r\n}}}\r\n\r\nIf I modify the test to print the results of `getClockTime` and `toCalendarTime`, I see\r\n{{{\r\nplumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs\r\nGHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 1] Compiling Main ( time002.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nLoading package array-0.3.0.2 ... linking ... done.\r\nLoading package filepath-1.2.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.6 ... linking ... done.\r\nLoading package unix-2.4.1.0 ... linking ... done.\r\nLoading package directory-1.1.0.0 ... linking ... done.\r\nLoading package process-1.0.1.5 ... linking ... done.\r\nLoading package time-1.2.0.3 ... linking ... done.\r\nLoading package random-1.0.0.3 ... linking ... done.\r\nLoading package haskell98-1.1.0.1 ... linking ... done.\r\nSat Feb 19 10:12:35 EST 2011\r\nCalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 35, ctPicosec = 112417000000, ctWDay = Saturday, ctYDay = 49, ctTZName = \"EST\", ctTZ = -18000, ctIsDST = False}\r\nOk.\r\n*Main> main\r\nSat Feb 19 10:12:37 EST 2011\r\nCalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 37, ctPicosec = 4295408225000000, ctWDay = Saturday, ctYDay = 49, ctTZName = \"EST\", ctTZ = -18000, ctIsDST = False}\r\n*** Exception: Time.toClockTime: picoseconds out of range\r\n*Main> \r\n}}}\r\nThe `ctPicosec` field is too big.\r\n\r\nThe interesting thing is that if I dump the relocations for HSold-time-1.0.0.6.o, and grep for `ctPicosec`, I see\r\n{{{\r\nplumbbob-franklin> otool -rv HSold-time-1.0.0.6.o | grep ctPicosec\r\n00023c5d False long True SUB False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info_dsp\r\n00023c5d False long True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info\r\n00023c55 True long True SIGNED False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_closure\r\n00001cf8 False quad True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info\r\n}}}\r\nThe first relocation is an `X86_64_RELOC_SUBTRACTOR`. This is probably being done incorrectly. (It may be distantly related to #4013, which also seems to be a subtractor relocation gone awry, but in that case of x86. The details of the x86 and x86_64 cases are quite different, but the original code for both cases is from the same author.)\r\n\r\nAfter the patch that fixed #4867, there between five and seven test failures that only involve `ghci`. I'm uncertain about two because I've been building unthreaded to simplify debugging and two tests require threads. I suspect linker bugs in all these cases.\r\n\r\nI've found a convenient list of x86_64 relocation examples at [http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528-SW1]. I'll check the OS X 64 bit linker in its current state against these. Unfortunately, the list does not seem to be exhaustive. For instance, it doesn't contain the inter-section relocation that was at issue in #4867.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7599timeout does not behave as expected2019-07-07T18:49:03Ziquetimeout does not behave as expectedIn trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positi...In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.
Below is a minimal test-case that I ran in ghci.
Import System.Timeout
Import Network
timeout (-1) $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns: Just {handle: \<socket: 9\>}
timeout 1000000 $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns Nothing
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"timeout does not behave as expected","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":["System.Timeout","base-4.6","timeout"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.\r\n\r\nWhen connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.\r\n\r\nBelow is a minimal test-case that I ran in ghci.\r\n\r\nImport System.Timeout\r\n\r\nImport Network\r\n\r\ntimeout (-1) $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns: Just {handle: <socket: 9>}\r\n\r\ntimeout 1000000 $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns Nothing","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13004Timeout no longer kills processes on timeout2019-07-07T18:24:09ZTamar ChristinaTimeout no longer kills processes on timeoutThere's a bug in timeout where processes aren't being killed on a timeout.
e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"` never ends
<details><summary>Trac metadata</summary>
| Trac field ...There's a bug in timeout where processes aren't being killed on a timeout.
e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"` never ends
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Timeout no longer kills processes on timeout","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There's a bug in timeout where processes aren't being killed on a timeout. \r\n\r\ne.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 \"sleep 10000s\"` never ends","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://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/10754truncate /= double2Int2019-07-07T18:34:10ZYuriy Syrovetskiytruncate /= double2IntThere is a rule in libraries/base/GHC/Float.hs:
```hs
"truncate/Double->Int" truncate = double2Int
```
But it is not true for some values. Particularly,
```hs
let infinity = 1/0 :: Double
truncate infinity :: Int == 0
double2Int infi...There is a rule in libraries/base/GHC/Float.hs:
```hs
"truncate/Double->Int" truncate = double2Int
```
But it is not true for some values. Particularly,
```hs
let infinity = 1/0 :: Double
truncate infinity :: Int == 0
double2Int infinity == -9223372036854775808 -- minBound
```
As a result, the value of `truncate (1/0 :: Double) :: Int` depends on optimization level.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"truncate /= double2Int","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["double2Int,","rewrite,","rule","truncate,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a rule in libraries/base/GHC/Float.hs:\r\n{{{#!hs\r\n\"truncate/Double->Int\" truncate = double2Int\r\n}}}\r\nBut it is not true for some values. Particularly,\r\n{{{#!hs\r\nlet infinity = 1/0 :: Double\r\ntruncate infinity :: Int == 0\r\ndouble2Int infinity == -9223372036854775808 -- minBound\r\n}}}\r\n\r\nAs a result, the value of {{{truncate (1/0 :: Double) :: Int}}} depends on optimization level.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/19288Type literals in Reflection of type constructor kinds leads to SafeHaskell vi...2021-02-05T21:10:33ZKyle EhrlichType literals in Reflection of type constructor kinds leads to SafeHaskell violation## Summary
[Data.Typeable.Internal#mkTypeLitFromString](https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Typeable.Internal.html#mkTypeLitFromString) has a typo which causes type Natural literals are tagged with the type S...## Summary
[Data.Typeable.Internal#mkTypeLitFromString](https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Typeable.Internal.html#mkTypeLitFromString) has a typo which causes type Natural literals are tagged with the type Symbol type constructor. This can be used to get a `TypeRep Nat` that is equal to the true `TypeRep Symbol`.
## Steps to reproduce
Run this program:
```hs
{-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeOperators, Safe #-}
module Main where
import Data.Maybe
import Data.Proxy
import Type.Reflection
import GHC.TypeLits
data Dat (x :: Proxy 1) = MkD1
evil :: Maybe (Nat :~~: Symbol)
evil = eqTypeRep (case (typeRepKind (typeRep :: TypeRep Dat)) of
(Fun (App _ x) _) -> typeRepKind x)
(typeRep :: TypeRep Symbol)
main :: IO ()
main = print (isJust evil)
```
The program prints True. This could easily be used to make an unsafeCast.
## Expected behavior
The program prints False
## Environment
* GHC version used: 8.10.39.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/10193TypeRep Show instance doesn't add parens around type operators2019-07-07T18:37:09Zpawel.nowakTypeRep Show instance doesn't add parens around type operatorsThe following code
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
{-# LANGUAGE TypeOperators #-}
import Data.Typeable
data a :*: b = Pair a b
main = print (typeOf (Pair 'a' 'b'))
```
prints
```hs
:*: Char Char
```
which is not valid Has...The following code
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
{-# LANGUAGE TypeOperators #-}
import Data.Typeable
data a :*: b = Pair a b
main = print (typeOf (Pair 'a' 'b'))
```
prints
```hs
:*: Char Char
```
which is not valid Haskell. I belive it should print
```hs
(:*:) Char Char
```
In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation:
```hs
let type_str = show $ Data.Typeable.typeOf wit
...
let expr_typesig = concat [parens e, " :: ", type_str]
```
What results in a parse error.
I can write a patch if someone confirms that's the desired behavior and doesn't break anything.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc3 |
| 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":"TypeRep Show instance doesn't add parens around type operators","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The following code\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AutoDeriveTypeable #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nimport Data.Typeable\r\n\r\ndata a :*: b = Pair a b\r\n\r\nmain = print (typeOf (Pair 'a' 'b'))\r\n}}}\r\n\r\nprints\r\n\r\n{{{#!hs\r\n:*: Char Char\r\n}}}\r\n\r\nwhich is not valid Haskell. I belive it should print\r\n\r\n{{{#!hs\r\n(:*:) Char Char\r\n}}}\r\n\r\nIn my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation:\r\n\r\n{{{#!hs\r\nlet type_str = show $ Data.Typeable.typeOf wit\r\n...\r\nlet expr_typesig = concat [parens e, \" :: \", type_str]\r\n}}}\r\nWhat results in a parse error.\r\n\r\nI can write a patch if someone confirms that's the desired behavior and doesn't break anything.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/6026Unboxed operators have wrong fixity2019-07-07T18:52:31ZbenlUnboxed operators have wrong fixity```
$ ghci -XMagicHash
$ :m GHC.Exts
> 1 + 2 * 3
7
> I# (1# +# 2# *# 3#)
9
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version |...```
$ ghci -XMagicHash
$ :m GHC.Exts
> 1 + 2 * 3
7
> I# (1# +# 2# *# 3#)
9
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unboxed operators have wrong fixity","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghci -XMagicHash\r\n$ :m GHC.Exts\r\n> 1 + 2 * 3\r\n7\r\n> I# (1# +# 2# *# 3#)\r\n9\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/18431Unboxed types in GHCi on big-endian platforms2023-10-25T09:03:58ZStefan Schulze FrielinghausUnboxed types in GHCi on big-endian platforms## Summary
Consider a file `test.hs` with content as follows:
```haskell
{-# LANGUAGE MagicHash #-}
module Main where
import GHC.Exts
data Foo = Foo Float# deriving Show
main = print $ Foo 1.0#
```
If compiled on s390x via LLVM backen...## Summary
Consider a file `test.hs` with content as follows:
```haskell
{-# LANGUAGE MagicHash #-}
module Main where
import GHC.Exts
data Foo = Foo Float# deriving Show
main = print $ Foo 1.0#
```
If compiled on s390x via LLVM backend and executed the expected output `Foo 1.0#` is printed to stdout. However, if interpreted via GHCi, the output is wrong:
```
> :load test.hs
> main
Foo 0.0#
```
This might be a big-endian bug. I tried to follow the execution of GHCi via GDB but got lost in to many continuations. I also had a look into parts of GHCi without luck. Any hint which parts of GHCi are responsible for interpreting unboxed types?
This is also the reason why test `T13825-debugger` fails on s390x.
Note, a similar bug regarding GHCi using `:print` is fixed by !3649.Stefan Schulze FrielinghausStefan Schulze Frielinghaushttps://gitlab.haskell.org/ghc/ghc/-/issues/4383Uncanonical display of Double2019-07-07T18:59:15Zdaniel.is.fischerUncanonical display of Double```
Prelude> 0.5 ^ 1030
0.8691694759794e-310
```
Should of course be 8.69...e-311, just to have it on record for now.
I'll take a look at the showing code one of the next days.
<details><summary>Trac metadata</summary>
| Trac field ...```
Prelude> 0.5 ^ 1030
0.8691694759794e-310
```
Should of course be 8.69...e-311, just to have it on record for now.
I'll take a look at the showing code one of the next days.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Uncanonical display of Double","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["Double,","show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nPrelude> 0.5 ^ 1030\r\n0.8691694759794e-310\r\n}}}\r\nShould of course be 8.69...e-311, just to have it on record for now.\r\n\r\nI'll take a look at the showing code one of the next days.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/4389Unexpcted failure, ambiguous type variable defaulted (ghci)2019-07-07T18:59:13Zdaniel.is.fischerUnexpcted failure, ambiguous type variable defaulted (ghci)```
=====> print019(ghci) 1444 of 2601 [0, 0, 0]
cd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/h...```
=====> print019(ghci) 1444 of 2601 [0, 0, 0]
cd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz -ignore-dot-ghci <print019.script >print019.run.stdout 2>print019.run.stderr
Actual stderr output differs from expected:
--- ./ghci.debugger/scripts/print019.stderr.normalised 2010-10-12 20:42:15.000000000 +0200
+++ ./ghci.debugger/scripts/print019.run.stderr.normalised 2010-10-12 20:42:15.000000000 +0200
@@ -1,7 +0,0 @@
-
-<interactive>:1:1:
- Ambiguous type variable `t1' in the constraint:
- (Show t1) arising from a use of `print'
- Cannot resolve unknown runtime types: t1
- Use :print or :force to determine these types
- In a stmt of an interactive GHCi command: print it
*** unexpected failure for print019(ghci)
```
Unexpectedly, the type variable was resolved.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpcted failure, ambiguous type variable defaulted (ghci)","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> print019(ghci) 1444 of 2601 [0, 0, 0]\r\ncd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz -ignore-dot-ghci <print019.script >print019.run.stdout 2>print019.run.stderr\r\nActual stderr output differs from expected:\r\n--- ./ghci.debugger/scripts/print019.stderr.normalised 2010-10-12 20:42:15.000000000 +0200\r\n+++ ./ghci.debugger/scripts/print019.run.stderr.normalised 2010-10-12 20:42:15.000000000 +0200\r\n@@ -1,7 +0,0 @@\r\n-\r\n-<interactive>:1:1:\r\n- Ambiguous type variable `t1' in the constraint:\r\n- (Show t1) arising from a use of `print'\r\n- Cannot resolve unknown runtime types: t1\r\n- Use :print or :force to determine these types\r\n- In a stmt of an interactive GHCi command: print it\r\n*** unexpected failure for print019(ghci)\r\n}}}\r\nUnexpectedly, the type variable was resolved.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://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":[]} -->