GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:52:01Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/6131-fprof-auto adds cost centers to INLINE functions2019-07-07T18:52:01Ztakano-akio-fprof-auto adds cost centers to INLINE functionsAccording to the Section 5.2 of User's Guide, -fprof-auto should add cost centers only to functions that are not marked INLINE. However GHC 7.4 doesn't respect this.
A simple example:
```
foo :: Integer -> Integer
foo x = x + 100
{-# I...According to the Section 5.2 of User's Guide, -fprof-auto should add cost centers only to functions that are not marked INLINE. However GHC 7.4 doesn't respect this.
A simple example:
```
foo :: Integer -> Integer
foo x = x + 100
{-# INLINE foo #-}
main = print $ loop (10000000::Int) 10000000000000000000000
where
loop 0 x = x
loop n x = loop (n-1) (foo x)
```
Compile and run this like:
```
% ghc -prof -fprof-auto -O2 test.hs
% ./test +RTS -p
% grep foo test.prof
```
And you will see 'foo' is listed as a cost center.
This happens with GHC 7.4.1 and 7.4.2-rc1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2-rc1 |
| 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":"-fprof-auto adds cost centers to INLINE functions","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the Section 5.2 of User's Guide, -fprof-auto should add cost centers only to functions that are not marked INLINE. However GHC 7.4 doesn't respect this.\r\n\r\nA simple example:\r\n\r\n{{{\r\nfoo :: Integer -> Integer\r\nfoo x = x + 100\r\n{-# INLINE foo #-}\r\n\r\nmain = print $ loop (10000000::Int) 10000000000000000000000\r\n where\r\n loop 0 x = x\r\n loop n x = loop (n-1) (foo x)\r\n}}}\r\n\r\nCompile and run this like:\r\n\r\n{{{\r\n% ghc -prof -fprof-auto -O2 test.hs\r\n% ./test +RTS -p\r\n% grep foo test.prof\r\n}}}\r\n\r\nAnd you will see 'foo' is listed as a cost center.\r\n\r\nThis happens with GHC 7.4.1 and 7.4.2-rc1","type_of_failure":"OtherFailure","blocking":[]} -->7.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/6130Weak pointer to MVar is finalized, even though MVar is still accessible2019-07-07T18:52:01ZjmillikinWeak pointer to MVar is finalized, even though MVar is still accessibleI'm seeing a problem mixing MVar and Weak: even though the MVar is still accessible from a function's scope (and the main thread is blocking on it), the Weak thinks it should be finalized.
Only seems to happen when compiled with -O2.
P...I'm seeing a problem mixing MVar and Weak: even though the MVar is still accessible from a function's scope (and the main thread is blocking on it), the Weak thinks it should be finalized.
Only seems to happen when compiled with -O2.
Platform: 64-bit Linux
Reproduced with GHC versions: 6.10.4, 6.12.3, 7.0.4, 7.2.2, 7.4.1
```
module Main (main) where
import Control.Concurrent
import Control.Monad (forever, forM_)
import Data.IORef
import System.Mem
import System.Mem.Weak
dispatchPendingCalls :: IORef [Weak (MVar ())] -> IO ()
dispatchPendingCalls ref = forever $ do
threadDelay 100000
pending <- atomicModifyIORef ref (\p -> ([], p))
forM_ pending (\weak -> do
maybeMVar <- deRefWeak weak
case maybeMVar of
Just mvar -> putMVar mvar ()
Nothing -> putStrLn "dispatchReply: weak mvar is Nothing")
call :: IORef [Weak (MVar ())] -> IO ()
call ref = do
mvar <- newEmptyMVar
weak <- mkWeakPtr mvar (Just (putStrLn "call: finalising weak"))
putStrLn "call: about to insert weak into list"
atomicModifyIORef ref (\p -> (weak : p, ()))
putStrLn "call: inserted weak into list"
performGC
takeMVar mvar
putStrLn "call: took from mvar"
main :: IO ()
main = do
pendingCalls <- newIORef []
_ <- forkIO (dispatchPendingCalls pendingCalls)
call pendingCalls
```
Expected output:
```
$ ghc --make WeakVar.hs
$ ./WeakMvar
call: about to insert weak into list
call: inserted weak into list
call: took from mvar
```
Actual output:
```
$ ghc --make -O2 WeakVar.hs
$ ./WeakMvar
call: about to insert weak into list
call: inserted weak into list
call: finalizing weak
dispatchReply: weak mvar is Nothing
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"Weak pointer to MVar is finalized, even though MVar is still accessible","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm seeing a problem mixing MVar and Weak: even though the MVar is still accessible from a function's scope (and the main thread is blocking on it), the Weak thinks it should be finalized.\r\n\r\nOnly seems to happen when compiled with -O2.\r\n\r\nPlatform: 64-bit Linux\r\nReproduced with GHC versions: 6.10.4, 6.12.3, 7.0.4, 7.2.2, 7.4.1\r\n\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport Control.Concurrent\r\nimport Control.Monad (forever, forM_)\r\nimport Data.IORef\r\nimport System.Mem\r\nimport System.Mem.Weak\r\n\r\ndispatchPendingCalls :: IORef [Weak (MVar ())] -> IO ()\r\ndispatchPendingCalls ref = forever $ do\r\n\tthreadDelay 100000\r\n\t\r\n\tpending <- atomicModifyIORef ref (\\p -> ([], p))\r\n\tforM_ pending (\\weak -> do\r\n\t\tmaybeMVar <- deRefWeak weak\r\n\t\tcase maybeMVar of\r\n\t\t\tJust mvar -> putMVar mvar ()\r\n\t\t\tNothing -> putStrLn \"dispatchReply: weak mvar is Nothing\")\r\n\r\ncall :: IORef [Weak (MVar ())] -> IO ()\r\ncall ref = do\r\n\tmvar <- newEmptyMVar\r\n\tweak <- mkWeakPtr mvar (Just (putStrLn \"call: finalising weak\"))\r\n\t\r\n\tputStrLn \"call: about to insert weak into list\"\r\n\tatomicModifyIORef ref (\\p -> (weak : p, ()))\r\n\tputStrLn \"call: inserted weak into list\"\r\n\tperformGC\r\n\ttakeMVar mvar\r\n\tputStrLn \"call: took from mvar\"\r\n\r\nmain :: IO ()\r\nmain = do\r\n\tpendingCalls <- newIORef []\r\n\t_ <- forkIO (dispatchPendingCalls pendingCalls)\r\n\tcall pendingCalls\r\n}}}\r\n\r\nExpected output:\r\n{{{\r\n$ ghc --make WeakVar.hs\r\n$ ./WeakMvar\r\ncall: about to insert weak into list\r\ncall: inserted weak into list\r\ncall: took from mvar\r\n}}}\r\n\r\nActual output:\r\n{{{\r\n$ ghc --make -O2 WeakVar.hs\r\n$ ./WeakMvar\r\ncall: about to insert weak into list\r\ncall: inserted weak into list\r\ncall: finalizing weak\r\ndispatchReply: weak mvar is Nothing\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6116ctrl-c doesn't always work when entering text in ghci2019-07-07T18:52:06Zjudahjctrl-c doesn't always work when entering text in ghciWith ghci-7.5.20120519 (on Mac and probably also Linux): type some text, then press ctrl-c. Then type more text, and press ctrl-c again. The first time you press ctrl-c, it starts a new line. But the second time you press ctrl-c, nothing...With ghci-7.5.20120519 (on Mac and probably also Linux): type some text, then press ctrl-c. Then type more text, and press ctrl-c again. The first time you press ctrl-c, it starts a new line. But the second time you press ctrl-c, nothing happens. (Actually running code from within ghci resets this process.)
This is a regression from the behavior of ghci-7.4.1, where every time you press ctrl-C it caused a new line to be printed.
From my initial investigation, I think this was caused by ghc commit 206c8fc3ebd64c40ae09742fdea09ffd0f915d5c, which was used to fix #2786.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| 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":"ctrl-c doesn't always work when entering text in ghci","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With ghci-7.5.20120519 (on Mac and probably also Linux): type some text, then press ctrl-c. Then type more text, and press ctrl-c again. The first time you press ctrl-c, it starts a new line. But the second time you press ctrl-c, nothing happens. (Actually running code from within ghci resets this process.)\r\n\r\nThis is a regression from the behavior of ghci-7.4.1, where every time you press ctrl-C it caused a new line to be printed.\r\n\r\nFrom my initial investigation, I think this was caused by ghc commit 206c8fc3ebd64c40ae09742fdea09ffd0f915d5c, which was used to fix #2786. ","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5962Data.Typeable: types which should compare equal don't2019-07-07T18:52:50ZGhost UserData.Typeable: types which should compare equal don'tHere are two ways to construct a TypeRep for the type () -\> ():
```
Prelude> import Data.Typeable
Prelude Data.Typeable> let unitToUnit = typeOf (\() -> ())
Prelude Data.Typeable> let unitToUnit' = mkFunTy (typeOf ()) (typeOf ())
```
...Here are two ways to construct a TypeRep for the type () -\> ():
```
Prelude> import Data.Typeable
Prelude Data.Typeable> let unitToUnit = typeOf (\() -> ())
Prelude Data.Typeable> let unitToUnit' = mkFunTy (typeOf ()) (typeOf ())
```
It seems to work:
```
Prelude Data.Typeable> unitToUnit
() -> ()
Prelude Data.Typeable> unitToUnit'
() -> ()
```
But the two TypeReps are not equal:
```
Prelude Data.Typeable> unitToUnit == unitToUnit'
False
```
<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":"Data.Typeable: types which should compare equal don't","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":"Here are two ways to construct a TypeRep for the type () -> ():\r\n\r\n{{{\r\nPrelude> import Data.Typeable\r\nPrelude Data.Typeable> let unitToUnit = typeOf (\\() -> ())\r\nPrelude Data.Typeable> let unitToUnit' = mkFunTy (typeOf ()) (typeOf ())\r\n}}}\r\n\r\nIt seems to work:\r\n\r\n{{{\r\nPrelude Data.Typeable> unitToUnit\r\n() -> ()\r\nPrelude Data.Typeable> unitToUnit'\r\n() -> ()\r\n}}}\r\n\r\nBut the two TypeReps are not equal:\r\n\r\n{{{\r\nPrelude Data.Typeable> unitToUnit == unitToUnit'\r\nFalse\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.3Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5870writeChan is not 100% exception-safe2019-07-07T18:53:11ZjoeyadamswriteChan is not 100% exception-safeControl.Concurrent.Chan.writeChan is currently implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
modifyMVar_ writeVar $ \old_hole -> do
putMVar old_hole (C...Control.Concurrent.Chan.writeChan is currently implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
modifyMVar_ writeVar $ \old_hole -> do
putMVar old_hole (ChItem val new_hole)
return new_hole
```
The problem is that modifyMVar_ restores the exception mask when it calls the callback. If an asynchronous exception is delivered immediately after the putMVar, the Chan's write end will be set to a filled hole, violating a key invariant.
I think it should be implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
mask_ $ do
old_hole <- takeMVar writeVar -- (1)
putMVar old_hole (ChItem val new_hole) -- (2)
putMVar writeVar new_hole -- (3)
```
This looks a bit naïve, but it should be atomic, at least in theory:
- (1) is interruptible. However, if it is interrupted, the MVar will remain intact.
- (2) is not interruptible, because old_hole is guaranteed to be empty. No other thread can fill it because we have taken exclusive access to writeVar.
- (3) is not interruptible, because we have taken exclusive access to writeVar.
This implementation has the added benefit of removing an exception handler, which should make it slightly faster.
readChan is okay, though:
```
readChan :: Chan a -> IO a
readChan (Chan readVar _) = do
modifyMVar readVar $ \read_end -> do
(ChItem val new_read_end) <- readMVar read_end
return (new_read_end, val)
```
If an exception is received immediately after the readMVar, then the read cursor will not be advanced, and the next call to readChan will simply read from that position again. Unfortunately, we can't get rid of the exception handler like we did with writeChan, because `readMVar read_end` is interruptible.
The attached patch changes the implementation of writeChan to the one shown above, and adds a comment to the definition of Chan about the write end's empty-hole invariant. I believe all of the Chan operations preserve this invariant, even the deprecated unGetChan and isEmptyChan.
I have not been able to create a test case where writeChan is interrupted between filling the hole and updating the write cursor. Perhaps it doesn't actually happen in practice, or perhaps it is extremely rare. But by my understanding of the semantics:
```
mask $ \restore -> do
thing1
restore $ putMVar ...
thing2
```
It is possible for an exception to arrive after the putMVar and before thing2.
<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":"writeChan is not 100% exception-safe","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":"Control.Concurrent.Chan.writeChan is currently implemented like this:\r\n\r\n{{{\r\nwriteChan :: Chan a -> a -> IO ()\r\nwriteChan (Chan _ writeVar) val = do\r\n new_hole <- newEmptyMVar\r\n modifyMVar_ writeVar $ \\old_hole -> do\r\n putMVar old_hole (ChItem val new_hole)\r\n return new_hole\r\n}}}\r\n\r\nThe problem is that modifyMVar_ restores the exception mask when it calls the callback. If an asynchronous exception is delivered immediately after the putMVar, the Chan's write end will be set to a filled hole, violating a key invariant.\r\n\r\nI think it should be implemented like this:\r\n\r\n{{{\r\nwriteChan :: Chan a -> a -> IO ()\r\nwriteChan (Chan _ writeVar) val = do\r\n new_hole <- newEmptyMVar\r\n mask_ $ do\r\n old_hole <- takeMVar writeVar -- (1)\r\n putMVar old_hole (ChItem val new_hole) -- (2)\r\n putMVar writeVar new_hole -- (3)\r\n}}}\r\n\r\nThis looks a bit naïve, but it should be atomic, at least in theory:\r\n\r\n * (1) is interruptible. However, if it is interrupted, the MVar will remain intact.\r\n\r\n * (2) is not interruptible, because old_hole is guaranteed to be empty. No other thread can fill it because we have taken exclusive access to writeVar.\r\n\r\n * (3) is not interruptible, because we have taken exclusive access to writeVar.\r\n\r\nThis implementation has the added benefit of removing an exception handler, which should make it slightly faster.\r\n\r\nreadChan is okay, though:\r\n\r\n{{{\r\nreadChan :: Chan a -> IO a\r\nreadChan (Chan readVar _) = do\r\n modifyMVar readVar $ \\read_end -> do\r\n (ChItem val new_read_end) <- readMVar read_end\r\n return (new_read_end, val)\r\n}}}\r\n\r\nIf an exception is received immediately after the readMVar, then the read cursor will not be advanced, and the next call to readChan will simply read from that position again. Unfortunately, we can't get rid of the exception handler like we did with writeChan, because {{{readMVar read_end}}} is interruptible.\r\n\r\nThe attached patch changes the implementation of writeChan to the one shown above, and adds a comment to the definition of Chan about the write end's empty-hole invariant. I believe all of the Chan operations preserve this invariant, even the deprecated unGetChan and isEmptyChan.\r\n\r\nI have not been able to create a test case where writeChan is interrupted between filling the hole and updating the write cursor. Perhaps it doesn't actually happen in practice, or perhaps it is extremely rare. But by my understanding of the semantics:\r\n\r\n{{{\r\nmask $ \\restore -> do\r\n thing1\r\n restore $ putMVar ...\r\n thing2\r\n}}}\r\n\r\nIt is possible for an exception to arrive after the putMVar and before thing2.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://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/5843hGetBufSome blocks when all available input is buffered (on Windows only)2019-07-07T18:53:21ZjoeyadamshGetBufSome blocks when all available input is buffered (on Windows only)See the attached program. On Windows, it blocks on hGetSome.
If I take out the hGetLine and hWaitForInput, hGetSome does not block. If I add \<code\>hSetBuffering h NoBuffering\</code\>, hGetBufSome still blocks after hWaitForInput beca...See the attached program. On Windows, it blocks on hGetSome.
If I take out the hGetLine and hWaitForInput, hGetSome does not block. If I add \<code\>hSetBuffering h NoBuffering\</code\>, hGetBufSome still blocks after hWaitForInput because it does some buffering when it calls hLookAhead_.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.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":"hGetBufSome blocks when all available input is buffered (on Windows only)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See the attached program. On Windows, it blocks on hGetSome.\r\n\r\nIf I take out the hGetLine and hWaitForInput, hGetSome does not block. If I add <code>hSetBuffering h NoBuffering</code>, hGetBufSome still blocks after hWaitForInput because it does some buffering when it calls hLookAhead_.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5838integer overflow in rts/RtsUtils:heapOverflow()2019-07-07T18:53:23ZHerbert Valerio Riedelhvr@gnu.orginteger overflow in rts/RtsUtils:heapOverflow()When failing with a heap exhaustion, the RTS truncates the **reported** *current maximum heap size* modulo 2\^32, e.g.
```
$ ghc +RTS -M4G -RTS -e 'sum [1..]'
Heap exhausted;
Current maximum heap size is 0 bytes (0 MB);
use `+RTS -M<siz...When failing with a heap exhaustion, the RTS truncates the **reported** *current maximum heap size* modulo 2\^32, e.g.
```
$ ghc +RTS -M4G -RTS -e 'sum [1..]'
Heap exhausted;
Current maximum heap size is 0 bytes (0 MB);
use `+RTS -M<size>' to increase it.
```
This is most probably due to `OutOfHeapHook()` already being called with the truncated value from `heapOverflow()`:
```c
void
heapOverflow(void)
{
if (!heap_overflow)
{
/* don't fflush(stdout); WORKAROUND bug in Linux glibc */
OutOfHeapHook(0/*unknown request size*/,
RtsFlags.GcFlags.maxHeapSize * BLOCK_SIZE);
heap_overflow = rtsTrue;
}
}
```
which multiplies `RtsFlags.GcFlags.maxHeapSize` and `BLOCK_SIZE` whose type are 32-bit `unsigned int`s, causing the result to be wrapped again into an `unsigned int`, whereas the result should be upcasted to a `long unsigned int` (which at least on 64bit archs would be equivalent to a C99 `uint64_t`)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.2 |
| 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":"integer overflow in rts/RtsUtils:heapOverflow()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When failing with a heap exhaustion, the RTS truncates the '''reported''' ''current maximum heap size'' modulo 2^32, e.g.\r\n\r\n{{{\r\n$ ghc +RTS -M4G -RTS -e 'sum [1..]'\r\nHeap exhausted;\r\nCurrent maximum heap size is 0 bytes (0 MB);\r\nuse `+RTS -M<size>' to increase it.\r\n}}}\r\n\r\nThis is most probably due to `OutOfHeapHook()` already being called with the truncated value from `heapOverflow()`:\r\n\r\n{{{\r\n#!c\r\nvoid\r\nheapOverflow(void)\r\n{\r\n if (!heap_overflow)\r\n {\r\n /* don't fflush(stdout); WORKAROUND bug in Linux glibc */\r\n OutOfHeapHook(0/*unknown request size*/,\r\n RtsFlags.GcFlags.maxHeapSize * BLOCK_SIZE);\r\n\r\n heap_overflow = rtsTrue;\r\n }\r\n}\r\n}}}\r\n\r\nwhich multiplies `RtsFlags.GcFlags.maxHeapSize` and `BLOCK_SIZE` whose type are 32-bit `unsigned int`s, causing the result to be wrapped again into an `unsigned int`, whereas the result should be upcasted to a `long unsigned int` (which at least on 64bit archs would be equivalent to a C99 `uint64_t`)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5818gcd and fizzled reversed in event SparkCounters2019-07-07T18:53:28ZMikolaj Konarskigcd and fizzled reversed in event SparkCountersThere is a bug in RTS when emitting the spark counters event:
the order of gcd and fizzled is reversed.
The precise line is probably this:
```
rts/eventlog/EventLog.c- postWord64(eb,counters.gcd);
```
but I think the spark counters ...There is a bug in RTS when emitting the spark counters event:
the order of gcd and fizzled is reversed.
The precise line is probably this:
```
rts/eventlog/EventLog.c- postWord64(eb,counters.gcd);
```
but I think the spark counters type should be changed
to match that of ghc-events
and similary the order in which +RTS -s prints them.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1-rc1 |
| 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":"gcd and fizzled reversed in event SparkCounters","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"duncan"},"version":"7.4.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a bug in RTS when emitting the spark counters event:\r\nthe order of gcd and fizzled is reversed.\r\nThe precise line is probably this:\r\n\r\n{{{\r\nrts/eventlog/EventLog.c- postWord64(eb,counters.gcd);\r\n}}}\r\n\r\nbut I think the spark counters type should be changed \r\nto match that of ghc-events\r\nand similary the order in which +RTS -s prints them.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/5807DPH library functions don't work without -fvectorise.2023-12-01T14:07:08ZbenlDPH library functions don't work without -fvectorise.Mukesh Tiwari reports:
```
ghci>import Data.Array.Parallel
ghci>import Data.Array.Parallel.PArray
ghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]
ghci>:t u
u :: PArray Double
ghci>u
fromList<PArray> [1.0,2.0,3.0,4.0,5.0,6....Mukesh Tiwari reports:
```
ghci>import Data.Array.Parallel
ghci>import Data.Array.Parallel.PArray
ghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]
ghci>:t u
u :: PArray Double
ghci>u
fromList<PArray> [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
ghci>let v = Data.Array.Parallel.fromPArrayP u
ghci>:t v
v :: [:Double:]
ghci>lengthP v
0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lengthP returns bad result","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"benl"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nMukesh Tiwari reports:\r\n\r\n{{{\r\nghci>import Data.Array.Parallel\r\nghci>import Data.Array.Parallel.PArray \r\nghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]\r\nghci>:t u\r\nu :: PArray Double\r\nghci>u\r\nfromList<PArray> [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]\r\nghci>let v = Data.Array.Parallel.fromPArrayP u\r\nghci>:t v\r\nv :: [:Double:]\r\nghci>lengthP v\r\n0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->⊥benlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/5800hp2ps produces unescaped backslashes for nested functions2019-07-07T18:53:32Zjkffhp2ps produces unescaped backslashes for nested functionsghc 7.4, when compiling with -prof -auto-all, includes nested functions as cost centres, sometimes including backslashes - e.g. it called one of my functions "foo.go.\\" in the profiling output.
hp2ps, in the file Key.c, function KeyEnt...ghc 7.4, when compiling with -prof -auto-all, includes nested functions as cost centres, sometimes including backslashes - e.g. it called one of my functions "foo.go.\\" in the profiling output.
hp2ps, in the file Key.c, function KeyEntry, does not escape backslashes in the 'name' parameter.
As a result, the ps file will contain an incorrect or unterminated string, causing it to be non-displayable or non-convertible to pdf.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hp2ps produces unescaped backslashes for nested functions","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc 7.4, when compiling with -prof -auto-all, includes nested functions as cost centres, sometimes including backslashes - e.g. it called one of my functions \"foo.go.\\\" in the profiling output.\r\n\r\nhp2ps, in the file Key.c, function KeyEntry, does not escape backslashes in the 'name' parameter.\r\n\r\nAs a result, the ps file will contain an incorrect or unterminated string, causing it to be non-displayable or non-convertible to pdf.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5783Data.Text.isPrefixOf fails to terminate2019-07-07T18:53:37ZreinerpData.Text.isPrefixOf fails to terminateThe function `Data.Text.isPrefixOf` fails to terminate with GHC 7.4-rc1, although it terminates with GHC-7.2. Reproduction instructions:
```
$ cd ghc-7.4.0.20111219
$ sudo make install
$ cabal -V
cabal-install version 0.10.2
using versi...The function `Data.Text.isPrefixOf` fails to terminate with GHC 7.4-rc1, although it terminates with GHC-7.2. Reproduction instructions:
```
$ cd ghc-7.4.0.20111219
$ sudo make install
$ cabal -V
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library
$ cabal install text-0.11.1.12
$ cd /tmp
$ cat >Test.hs
import Data.Text
main = print (pack "A" `isPrefixOf` pack "AB")
$ runghc Test.hs
<program hangs on 100% CPU use, without producing any output>
```
Unfortunately, it appears to be rather difficult to create a reduced test case; the problem disappears when I make any attempt to minimize it.
I have verified this on Mac OS X 10.7.2 and 64-bit Ubuntu 10.10.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1-rc1 |
| 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":"Data.Text.isPrefixOf fails to terminate","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The function {{{Data.Text.isPrefixOf}}} fails to terminate with GHC 7.4-rc1, although it terminates with GHC-7.2. Reproduction instructions:\r\n\r\n{{{\r\n$ cd ghc-7.4.0.20111219\r\n$ sudo make install\r\n$ cabal -V\r\ncabal-install version 0.10.2\r\nusing version 1.10.1.0 of the Cabal library \r\n$ cabal install text-0.11.1.12\r\n$ cd /tmp\r\n$ cat >Test.hs\r\nimport Data.Text\r\nmain = print (pack \"A\" `isPrefixOf` pack \"AB\")\r\n$ runghc Test.hs\r\n<program hangs on 100% CPU use, without producing any output>\r\n}}}\r\n\r\nUnfortunately, it appears to be rather difficult to create a reduced test case; the problem disappears when I make any attempt to minimize it.\r\n\r\nI have verified this on Mac OS X 10.7.2 and 64-bit Ubuntu 10.10.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5751code works in 7.0 but hangs in 7.2/7.4 due to changes in type checker (most l...2019-07-07T18:53:45ZJeremyShawcode works in 7.0 but hangs in 7.2/7.4 due to changes in type checker (most likely)I have a function with the lovely type signature:
```
homePage :: (Happstack m,
MonadRoute m,
MonadUser m,
HasAppConf m,
ToMessage (HSX.XML m),
MonadRender m,
...I have a function with the lovely type signature:
```
homePage :: (Happstack m,
MonadRoute m,
MonadUser m,
HasAppConf m,
ToMessage (HSX.XML m),
MonadRender m,
Ontology.MkURL (URL m),
EmbedAsAttr m (Attr String (URL m))) =>
m Response
```
The code works fine in 7.0 but hangs (at runtime) under 7.2 and 7.4rc1.
If I change that type signature to the more specific type:
```
homePage :: AppPart' Response
```
Then the code starts working again.
This bug reminds me a lot of these previously closed bugs:
#4809 #3731
I will follow up with an isolated test case in the next couple days. It will likely take some time to tease out the relevant parts of the code into something more manageable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.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":"code works in 7.0 but hangs in 7.2/7.4 due to changes in type checker (most likely)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a function with the lovely type signature:\r\n\r\n{{{\r\nhomePage :: (Happstack m, \r\n MonadRoute m,\r\n MonadUser m, \r\n HasAppConf m, \r\n ToMessage (HSX.XML m), \r\n MonadRender m, \r\n Ontology.MkURL (URL m),\r\n EmbedAsAttr m (Attr String (URL m))) =>\r\n m Response\r\n}}}\r\n\r\nThe code works fine in 7.0 but hangs (at runtime) under 7.2 and 7.4rc1.\r\n\r\nIf I change that type signature to the more specific type:\r\n\r\n{{{\r\nhomePage :: AppPart' Response\r\n}}}\r\n\r\nThen the code starts working again.\r\n\r\nThis bug reminds me a lot of these previously closed bugs:\r\n\r\n#4809 #3731\r\n\r\nI will follow up with an isolated test case in the next couple days. It will likely take some time to tease out the relevant parts of the code into something more manageable.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5747Floating point error with -msse22019-07-07T18:53:46Zlennart@augustsson.netFloating point error with -msse2Compile and run this program:
```
main = print (cos 0)
```
And you get
```
$ ghc -O2 -fforce-recomp -msse2 Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main.exe ...
$ ./Main
5.249681779125557e-308
```
(This...Compile and run this program:
```
main = print (cos 0)
```
And you get
```
$ ghc -O2 -fforce-recomp -msse2 Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main.exe ...
$ ./Main
5.249681779125557e-308
```
(This is a bug in ghc 7.2.2, but that 7.2.2 is not one of the available version choices.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Floating point error with -msse2","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compile and run this program:\r\n{{{\r\nmain = print (cos 0)\r\n}}}\r\nAnd you get\r\n{{{\r\n$ ghc -O2 -fforce-recomp -msse2 Main.hs\r\n[1 of 1] Compiling Main ( Main.hs, Main.o )\r\nLinking Main.exe ...\r\n$ ./Main\r\n5.249681779125557e-308\r\n}}}\r\n\r\n(This is a bug in ghc 7.2.2, but that 7.2.2 is not one of the available version choices.)","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5680Main thread does not respect stack size RTS options2019-07-07T18:54:04Zravi_nMain thread does not respect stack size RTS optionsI was recently trying to start up with a large initial stack in a Haskell program so that I could give a large stack to some foreign code I was calling. Unfortunately, no matter what I did with the -K -ki and -kc RTS options, the stack s...I was recently trying to start up with a large initial stack in a Haskell program so that I could give a large stack to some foreign code I was calling. Unfortunately, no matter what I did with the -K -ki and -kc RTS options, the stack size never seemed to change.
I suspect the problem can be traced to the the following comment in source:rts/RtsMain.c
`/* ToDo: want to start with a larger stack size */`
It looks to me like the main thread is started without attempting to adjust its stack size based on the RTS flags. Is that correct? If so, how hard is it to fix?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.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":"Main thread does not respect stack size RTS options","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was recently trying to start up with a large initial stack in a Haskell program so that I could give a large stack to some foreign code I was calling. Unfortunately, no matter what I did with the -K -ki and -kc RTS options, the stack size never seemed to change.\r\n\r\nI suspect the problem can be traced to the the following comment in source:rts/RtsMain.c\r\n\r\n`/* ToDo: want to start with a larger stack size */`\r\n\r\nIt looks to me like the main thread is started without attempting to adjust its stack size based on the RTS flags. Is that correct? If so, how hard is it to fix?","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/5640Retainer profiling broken2019-07-07T18:54:14Zlennart@augustsson.netRetainer profiling brokenI tried to profile with the following flags:
```
foo +RTS -i0.5 -hr -hcTransformType -RTS ...
```
The resulting .hp file has currupt time stamps. Here they are:
```
BEGIN_SAMPLE 0.00
BEGIN_SAMPLE 0.79
BEGIN_SAMPLE 1.38
BEGIN_SAMPLE 1....I tried to profile with the following flags:
```
foo +RTS -i0.5 -hr -hcTransformType -RTS ...
```
The resulting .hp file has currupt time stamps. Here they are:
```
BEGIN_SAMPLE 0.00
BEGIN_SAMPLE 0.79
BEGIN_SAMPLE 1.38
BEGIN_SAMPLE 1.65
BEGIN_SAMPLE 1.31
BEGIN_SAMPLE 0.4294967237
BEGIN_SAMPLE 4294967294.4294967266
BEGIN_SAMPLE 4294967294.4294967266
BEGIN_SAMPLE 4294967294.4294967291
BEGIN_SAMPLE 4294967295.4294967212
BEGIN_SAMPLE 4294967295.4294967220
BEGIN_SAMPLE 4294967295.4294967223
BEGIN_SAMPLE 4294967295.4294967225
BEGIN_SAMPLE 4294967295.4294967217
BEGIN_SAMPLE 4294967295.4294967206
BEGIN_SAMPLE 4294967295.4294967264
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Retainer profiling broken","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to profile with the following flags:\r\n{{{\r\nfoo +RTS -i0.5 -hr -hcTransformType -RTS ...\r\n}}}\r\nThe resulting .hp file has currupt time stamps. Here they are:\r\n{{{\r\nBEGIN_SAMPLE 0.00\r\nBEGIN_SAMPLE 0.79\r\nBEGIN_SAMPLE 1.38\r\nBEGIN_SAMPLE 1.65\r\nBEGIN_SAMPLE 1.31\r\nBEGIN_SAMPLE 0.4294967237\r\nBEGIN_SAMPLE 4294967294.4294967266\r\nBEGIN_SAMPLE 4294967294.4294967266\r\nBEGIN_SAMPLE 4294967294.4294967291\r\nBEGIN_SAMPLE 4294967295.4294967212\r\nBEGIN_SAMPLE 4294967295.4294967220\r\nBEGIN_SAMPLE 4294967295.4294967223\r\nBEGIN_SAMPLE 4294967295.4294967225\r\nBEGIN_SAMPLE 4294967295.4294967217\r\nBEGIN_SAMPLE 4294967295.4294967206\r\nBEGIN_SAMPLE 4294967295.4294967264\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5626Miscompilation, exception omitted with -O2019-07-07T18:54:18Zmichal.palkaMiscompilation, exception omitted with -OFollowing program is miscompiled when compiled with `-O`.
```
module Main where
wrap x = [x]!!0
f :: [Int] -> a
f a = foldr (\b -> \c -> c) (undefined ()) (a ++ a) 0
main = do
print $ (f [] :: String)
print $ wrap $ (f [] :: Int)...Following program is miscompiled when compiled with `-O`.
```
module Main where
wrap x = [x]!!0
f :: [Int] -> a
f a = foldr (\b -> \c -> c) (undefined ()) (a ++ a) 0
main = do
print $ (f [] :: String)
print $ wrap $ (f [] :: Int)
print $ wrap $ (f [] :: (Int, Int, Int, Int))
```
The result of running it on my machine (Linux x86-64) is following:
```
"
1099511628032
zsh: segmentation fault ./test7
```
Looking at the Core it seems that instead of the expected `undefined` a partially-applied function is returned. GHC 7.3.20111022 was used for testing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michal.palka@poczta.fm |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Miscompilation, exception omitted with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["exception","miscompilation","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":["michal.palka@poczta.fm"],"type":"Bug","description":"Following program is miscompiled when compiled with `-O`.\r\n{{{\r\nmodule Main where\r\n\r\nwrap x = [x]!!0\r\n\r\nf :: [Int] -> a\r\nf a = foldr (\\b -> \\c -> c) (undefined ()) (a ++ a) 0\r\n\r\nmain = do\r\n print $ (f [] :: String)\r\n print $ wrap $ (f [] :: Int)\r\n print $ wrap $ (f [] :: (Int, Int, Int, Int))\r\n}}}\r\n\r\nThe result of running it on my machine (Linux x86-64) is following:\r\n{{{\r\n\"\r\n1099511628032\r\nzsh: segmentation fault ./test7\r\n}}}\r\n\r\nLooking at the Core it seems that instead of the expected `undefined` a partially-applied function is returned. GHC 7.3.20111022 was used for testing.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5625Code using seq has wrong strictness when unoptimised (too lazy)2019-07-07T18:54:18Zmichal.palkaCode using seq has wrong strictness when unoptimised (too lazy)The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id ...The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id [0])` when compiled with `-O0`. It was tested with GHC 7.3.20111022.
```
main = do
let a = \x -> seq undefined (+1)
print $ (a `seq` a [] `seq` id) [0]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michal.palka@poczta.fm |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Code using seq has wrong strictness when unoptimised (too lazy)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["lazy","seq","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":["michal.palka@poczta.fm"],"type":"Bug","description":"The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id [0])` when compiled with `-O0`. It was tested with GHC 7.3.20111022.\r\n\r\n{{{\r\nmain = do\r\n let a = \\x -> seq undefined (+1)\r\n print $ (a `seq` a [] `seq` id) [0]\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5614recompilation bug with -O2019-07-07T18:54:21Zgmi001recompilation bug with -ORecompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.
Test case:
1) build the app with GHC --make -O Main.hs
2) run Main (output = B)
3) change and save in X.hs
> x = D {...Recompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.
Test case:
1) build the app with GHC --make -O Main.hs
2) run Main (output = B)
3) change and save in X.hs
> x = D { f = B }
> to
> x = D { f = A }
4) rebuild the app with GHC --make -O Main.hs (recompiles only X.hs)
5) run Main (unexpected output = B)
6) force recompilation of both X.hs and Main.hs
7) run Main (output = A)
The bug is in -O.
A similar test with f :: String instead of f :: D2 runs without problems.
Problem is tested positive on WIN GHC 7.0.2, OpenSuse GHC 6.12.3, Mac OS X GHC 7.0.3 and GHC 7.2.1 (MAC?).
for more detail see http://sourceforge.net/apps/trac/ampersand/ticket/172.
the closed #1959 and #3166 describe similar problems.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.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":"recompilation bug with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":["recompilation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Recompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.\r\n\r\nTest case:\r\n\r\n1) build the app with GHC --make -O Main.hs\r\n\r\n2) run Main (output = B)\r\n\r\n3) change and save in X.hs\r\n\r\n x = D { f = B }\r\n\r\n to\r\n\r\n x = D { f = A }\r\n\r\n4) rebuild the app with GHC --make -O Main.hs (recompiles only X.hs) \r\n\r\n5) run Main (unexpected output = B)\r\n\r\n6) force recompilation of both X.hs and Main.hs\r\n\r\n7) run Main (output = A)\r\n\r\nThe bug is in -O.\r\nA similar test with f :: String instead of f :: D2 runs without problems.\r\n\r\nProblem is tested positive on WIN GHC 7.0.2, OpenSuse GHC 6.12.3, Mac OS X GHC 7.0.3 and GHC 7.2.1 (MAC?).\r\n\r\nfor more detail see http://sourceforge.net/apps/trac/ampersand/ticket/172.\r\n\r\nthe closed #1959 and #3166 describe similar problems.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5594stdout is not flushed using custom main2019-07-07T18:54:35Zhandonsonstdout is not flushed using custom mainAccording to the [using your own main()](http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main) guide, Prepare two files.
main.c:
```
#include <stdio.h>
#include "HsFFI.h"
#ifdef __GLASGOW_HASKELL__
#incl...According to the [using your own main()](http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main) guide, Prepare two files.
main.c:
```
#include <stdio.h>
#include "HsFFI.h"
#ifdef __GLASGOW_HASKELL__
#include "Vomit_stub.h"
#endif
int main(int argc, char *argv[])
{
int i;
hs_init(&argc, &argv);
vomit();
hs_exit();
return 0;
}
```
Vomit.hs:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE OverloadedStrings #-}
module Vomit where
import Data.ByteString
import Data.ByteString.Char8 ()
import Prelude hiding (putStr)
foreign export ccall vomit :: IO ()
vomit = putStr "Wrrreerrerek\n"
```
Compile the code:
```
$ ghc -c Vomit.hs
$ ghc --make -no-hs-main -optc-O main.c Vomit -o main
```
Run:
```
$ ./main
Wrrreerrerek
$
```
Looks fine. However:
```
$ ./main > output.txt
$ cat output.txt
$
```
output.txt is empty.
It seems when the output is done by some Haskell code called by a C code, and the stdout is redirected to a file, the output is not properly flushed. Changing Vomit.hs to:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE OverloadedStrings #-}
module Vomit where
import Data.ByteString
import Data.ByteString.Char8 ()
import Prelude hiding (putStr)
import System.IO (hFlush, stdout)
foreign export ccall vomit :: IO ()
vomit = putStr "Wrrreerrerek\n" >> hFlush stdout
```
which manually flushes stdout, fixes the behavior.
Since hs_exit() on the C side is supposed to terminate the RTS and flush all output, this seems to be a bug.
Tested with GHC 7.0.4 on Debian GNU/Linux for x86.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.4 |
| 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":"stdout is not flushed using custom main","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the [http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main using your own main()] guide, Prepare two files.\r\n\r\nmain.c:\r\n\r\n{{{\r\n#include <stdio.h>\r\n#include \"HsFFI.h\"\r\n\r\n#ifdef __GLASGOW_HASKELL__\r\n#include \"Vomit_stub.h\"\r\n#endif\r\n\r\nint main(int argc, char *argv[])\r\n{\r\n int i;\r\n\r\n hs_init(&argc, &argv);\r\n\r\n vomit();\r\n\r\n hs_exit();\r\n return 0;\r\n}\r\n}}}\r\n\r\nVomit.hs:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nmodule Vomit where\r\n\r\nimport Data.ByteString\r\nimport Data.ByteString.Char8 ()\r\nimport Prelude hiding (putStr)\r\n\r\nforeign export ccall vomit :: IO ()\r\nvomit = putStr \"Wrrreerrerek\\n\"\r\n}}}\r\n\r\nCompile the code:\r\n\r\n{{{\r\n$ ghc -c Vomit.hs\r\n$ ghc --make -no-hs-main -optc-O main.c Vomit -o main\r\n}}}\r\n\r\nRun:\r\n\r\n{{{\r\n$ ./main\r\nWrrreerrerek\r\n$\r\n}}}\r\n\r\nLooks fine. However:\r\n\r\n{{{\r\n$ ./main > output.txt\r\n$ cat output.txt\r\n$\r\n}}}\r\n\r\noutput.txt is empty.\r\n\r\nIt seems when the output is done by some Haskell code called by a C code, and the stdout is redirected to a file, the output is not properly flushed. Changing Vomit.hs to:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nmodule Vomit where\r\n\r\nimport Data.ByteString\r\nimport Data.ByteString.Char8 ()\r\nimport Prelude hiding (putStr)\r\n\r\nimport System.IO (hFlush, stdout)\r\n\r\nforeign export ccall vomit :: IO ()\r\nvomit = putStr \"Wrrreerrerek\\n\" >> hFlush stdout\r\n}}}\r\n\r\nwhich manually flushes stdout, fixes the behavior.\r\n\r\nSince hs_exit() on the C side is supposed to terminate the RTS and flush all output, this seems to be a bug.\r\n\r\nTested with GHC 7.0.4 on Debian GNU/Linux for x86.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlow