GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:01:00Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4036Compiled FFI static imports are invalid when imported in GHCI2019-07-07T19:01:00ZjmillikinCompiled FFI static imports are invalid when imported in GHCIWhen I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in \#haskell, and tommd suggested that this might be ...When I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in \#haskell, and tommd suggested that this might be an architecture-dependent error in GHC.
Here's the code used to reproduce the problem. I'm using `sys_siglist` declared in `<signal.h>`, since it's similar to how I originally found the problem, but I suspect this will occur for any static data.
Given the following modules:
```
-- A.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module A where
import Foreign
import Foreign.C
foreign import ccall "&sys_siglist"
siglist_a :: Ptr CString
```
```
-- B.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module B where
import Foreign
import Foreign.C
foreign import ccall "&sys_siglist"
siglist_b :: Ptr CString
```
```
-- Main.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C
import A
import B
foreign import ccall "&sys_siglist"
siglist_main :: Ptr CString
main = do
putStrLn $ "siglist_a = " ++ show siglist_a
putStrLn $ "siglist_b = " ++ show siglist_b
putStrLn $ "siglist_main = " ++ show siglist_main
peekSiglist "a " siglist_a
peekSiglist "b " siglist_b
peekSiglist "main" siglist_main
peekSiglist name siglist = do
ptr <- peekElemOff siglist 2
str <- maybePeek peekCString ptr
putStrLn $ "siglist_" ++ name ++ "[2] = " ++ show str
```
Running the application via GHCI gives correct output:
```
$ runhaskell Main.hs
siglist_a = 0x00007f53a948fe00
siglist_b = 0x00007f53a948fe00
siglist_main = 0x00007f53a948fe00
siglist_a [2] = Just "Interrupt"
siglist_b [2] = Just "Interrupt"
siglist_main[2] = Just "Interrupt"
```
However, if one of them is compiled, its pointer will be invalid:
```
$ ghc -c A.hs
$ runhaskell Main.hs
siglist_a = 0x0000000040378918
siglist_b = 0x00007fe7c029ce00
siglist_main = 0x00007fe7c029ce00
siglist_a [2] = Nothing
siglist_b [2] = Just "Interrupt"
siglist_main[2] = Just "Interrupt"
```
I thought this might be related to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiled FFI static imports are invalid when imported in GHCI","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in #haskell, and tommd suggested that this might be an architecture-dependent error in GHC.\r\n\r\nHere's the code used to reproduce the problem. I'm using {{{sys_siglist}}} declared in {{{<signal.h>}}}, since it's similar to how I originally found the problem, but I suspect this will occur for any static data.\r\n\r\nGiven the following modules:\r\n\r\n{{{\r\n-- A.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule A where\r\nimport Foreign\r\nimport Foreign.C\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_a :: Ptr CString\r\n}}}\r\n\r\n{{{\r\n-- B.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule B where\r\nimport Foreign\r\nimport Foreign.C\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_b :: Ptr CString\r\n}}}\r\n\r\n{{{\r\n-- Main.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule Main where\r\nimport Foreign\r\nimport Foreign.C\r\nimport A\r\nimport B\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_main :: Ptr CString\r\n\r\nmain = do\r\n putStrLn $ \"siglist_a = \" ++ show siglist_a\r\n putStrLn $ \"siglist_b = \" ++ show siglist_b\r\n putStrLn $ \"siglist_main = \" ++ show siglist_main\r\n\r\n peekSiglist \"a \" siglist_a\r\n peekSiglist \"b \" siglist_b\r\n peekSiglist \"main\" siglist_main\r\n\r\npeekSiglist name siglist = do\r\n ptr <- peekElemOff siglist 2\r\n str <- maybePeek peekCString ptr\r\n putStrLn $ \"siglist_\" ++ name ++ \"[2] = \" ++ show str\r\n}}}\r\n\r\nRunning the application via GHCI gives correct output:\r\n\r\n{{{\r\n$ runhaskell Main.hs \r\nsiglist_a = 0x00007f53a948fe00\r\nsiglist_b = 0x00007f53a948fe00\r\nsiglist_main = 0x00007f53a948fe00\r\nsiglist_a [2] = Just \"Interrupt\"\r\nsiglist_b [2] = Just \"Interrupt\"\r\nsiglist_main[2] = Just \"Interrupt\"\r\n}}}\r\n\r\nHowever, if one of them is compiled, its pointer will be invalid:\r\n\r\n{{{\r\n$ ghc -c A.hs\r\n$ runhaskell Main.hs \r\nsiglist_a = 0x0000000040378918\r\nsiglist_b = 0x00007fe7c029ce00\r\nsiglist_main = 0x00007fe7c029ce00\r\nsiglist_a [2] = Nothing\r\nsiglist_b [2] = Just \"Interrupt\"\r\nsiglist_main[2] = Just \"Interrupt\"\r\n}}}\r\n\r\nI thought this might be related to ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4041possible misbehaviour of hGet/hGetBuf2019-07-07T19:00:59Zduncanpossible misbehaviour of hGet/hGetBufnominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.
Simon Marlow recently added this documentation to `ByteS...nominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.
Simon Marlow recently added this documentation to `ByteString.hGet`:
```
-- If there is any data to read, then 'hGet' will not block, instead
-- it will return whatever data is available without blocking. It
-- only blocks if there is no data available to read.
```
nominolo reports that with ghc-6.12.1 on OSX SL, that the actual behaviour is that `hGet` blocks until all the requested data is available, that is, it does not return a short read.
Simon clearly thinks that the documented behaviour of hGet is what the behaviour ought to be. In a previous patch to the `ByteString` package he writes:
```
Mon Mar 22 15:39:14 GMT 2010 Simon Marlow <marlowsd@gmail.com>
* hGetContents: use hGet instead of hGetNonBlocking + hWaitForInput + hIsEOF
Not only is this cleaner, but it fixes a problem with read binary data
over a pipe, see
http://hackage.haskell.org/trac/ghc/ticket/3808
The problem is that bytestring normally works fine when the Handle is
not in binary mode, because it uses hGetBuf/hPutBuf which bypass the
encoding layer. That is, except in this one particular case:
hWaitForInput might do some decoding, because it has to determine
whether there are any characters (not bytes) available to be read.
I imagine hGetNonBlocking was used due to concerns that hGet might
block if there is insufficient data, but that's not the case; hGet
returns a short read if it would otherwise block, and only blocks if
there is no data to read.
```
So it's not entirely clear what is going on. It's either confusion or a bug (possibly a system-dependent one).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"possible misbehaviour of hGet/hGetBuf","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"nominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.\r\n\r\nSimon Marlow recently added this documentation to `ByteString.hGet`:\r\n{{{\r\n-- If there is any data to read, then 'hGet' will not block, instead\r\n-- it will return whatever data is available without blocking. It\r\n-- only blocks if there is no data available to read.\r\n}}}\r\nnominolo reports that with ghc-6.12.1 on OSX SL, that the actual behaviour is that `hGet` blocks until all the requested data is available, that is, it does not return a short read.\r\n\r\nSimon clearly thinks that the documented behaviour of hGet is what the behaviour ought to be. In a previous patch to the `ByteString` package he writes:\r\n{{{\r\nMon Mar 22 15:39:14 GMT 2010 Simon Marlow <marlowsd@gmail.com>\r\n * hGetContents: use hGet instead of hGetNonBlocking + hWaitForInput + hIsEOF\r\n \r\n Not only is this cleaner, but it fixes a problem with read binary data\r\n over a pipe, see\r\n http://hackage.haskell.org/trac/ghc/ticket/3808\r\n \r\n The problem is that bytestring normally works fine when the Handle is\r\n not in binary mode, because it uses hGetBuf/hPutBuf which bypass the\r\n encoding layer. That is, except in this one particular case:\r\n hWaitForInput might do some decoding, because it has to determine\r\n whether there are any characters (not bytes) available to be read.\r\n \r\n I imagine hGetNonBlocking was used due to concerns that hGet might\r\n block if there is insufficient data, but that's not the case; hGet\r\n returns a short read if it would otherwise block, and only blocks if\r\n there is no data to read.\r\n}}}\r\n\r\nSo it's not entirely clear what is going on. It's either confusion or a bug (possibly a system-dependent one).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4049Support for ABI versioning of C libraries2019-07-07T19:00:57ZmpiechotkaSupport for ABI versioning of C librariesCurrently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts an...Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.
More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| 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":"Support for ldscripts and ABI versioning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.\r\n\r\nAlso it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.\r\n\r\nMore informations:\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=290974\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=311361","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4057Modifying TVar after calling always causes freeze/spin in GHCi2019-07-07T19:00:55ZBaughnModifying TVar after calling always causes freeze/spin in GHCiThe attached code, if run under GHCi, causes GHCi to freeze while spinning the CPU. It works correctly when compiled, or if the "\>\> modifyTVar" part of f is commented out.
(For the curious: Yes, I believed always does what check does....The attached code, if run under GHCi, causes GHCi to freeze while spinning the CPU. It works correctly when compiled, or if the "\>\> modifyTVar" part of f is commented out.
(For the curious: Yes, I believed always does what check does. Thankfully nothing had made its way into production code, because of this bug. The documentation should probably be clarified.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Modifying TVar after calling always causes freeze/spin in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached code, if run under GHCi, causes GHCi to freeze while spinning the CPU. It works correctly when compiled, or if the \">> modifyTVar\" part of f is commented out.\r\n\r\n(For the curious: Yes, I believed always does what check does. Thankfully nothing had made its way into production code, because of this bug. The documentation should probably be clarified.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4059possible error in foreign wrapper reentering Haskell2019-07-07T19:00:53Zaruizpossible error in foreign wrapper reentering HaskellThe following simple code works as expected in 6.12.1, 6.10, and all previous ghc versions:
fun.c:
```
double deriv(double f(double), double x, double h)
{
return (f(x+h)-f(x))/h;
}
```
pru.hs:
```
{-# LANGUAGE ForeignFunctionIn...The following simple code works as expected in 6.12.1, 6.10, and all previous ghc versions:
fun.c:
```
double deriv(double f(double), double x, double h)
{
return (f(x+h)-f(x))/h;
}
```
pru.hs:
```
{-# LANGUAGE ForeignFunctionInterface #-}
import Foreign
d f x = unsafePerformIO $ do
g <- mkfun f
r <- deriv g x 0.01
return r
main = do
print $ d sin 0
print $ d (\x-> x * d (\y-> x+y) 1) 1
foreign import ccall safe "deriv" deriv :: FunPtr (Double->Double) -> Double -> Double -> IO Double
foreign import ccall safe "wrapper" mkfun:: (Double -> Double) -> IO( FunPtr (Double -> Double))
```
$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.12.1
$ ghc --make pru.hs fun.c -fforce-recomp
\[1 of 1\] Compiling Main ( pru.hs, pru.o )
Linking pru ...
$ ./pru
1. 9999833334166665
1. 000000000004464
But it gives a wrong result in ghc-6.12.2:
$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.12.2
$ ghc --make pru.hs fun.c -fforce-recomp
\[1 of 1\] Compiling Main ( pru.hs, pru.o )
Linking pru ...
$ ./pru
1. 9999833334166665
1. 0
I have discovered this problem when a similar test in my hmatrix library failed in 6.12.2. As shown above, it seems that the wrapper only fails on C functions which call back to Haskell.
Linux 2.6.28-17-generic #58-Ubuntu SMP
ghc-6.12.2-i386-unknown-linux-n.tar.bz2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"possible error in foreign wrapper reentering Haskell","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following simple code works as expected in 6.12.1, 6.10, and all previous ghc versions:\r\n\r\nfun.c:\r\n{{{\r\ndouble deriv(double f(double), double x, double h)\r\n{\r\n return (f(x+h)-f(x))/h;\r\n}\r\n\r\n}}}\r\n\r\n\r\n\r\npru.hs:\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\nimport Foreign\r\n\r\nd f x = unsafePerformIO $ do\r\n g <- mkfun f\r\n r <- deriv g x 0.01\r\n return r\r\n\r\nmain = do\r\n print $ d sin 0\r\n print $ d (\\x-> x * d (\\y-> x+y) 1) 1\r\n\r\n\r\nforeign import ccall safe \"deriv\" deriv :: FunPtr (Double->Double) -> Double -> Double -> IO Double\r\n\r\nforeign import ccall safe \"wrapper\" mkfun:: (Double -> Double) -> IO( FunPtr (Double -> Double)) \r\n\r\n}}}\r\n\r\n$ ghc -V\r\n\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.1\r\n\r\n$ ghc --make pru.hs fun.c -fforce-recomp\r\n\r\n[1 of 1] Compiling Main ( pru.hs, pru.o )\r\n\r\nLinking pru ...\r\n\r\n$ ./pru\r\n\r\n0.9999833334166665\r\n\r\n1.000000000004464\r\n\r\n\r\n\r\nBut it gives a wrong result in ghc-6.12.2:\r\n\r\n$ ghc -V\r\n\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.2\r\n\r\n$ ghc --make pru.hs fun.c -fforce-recomp\r\n\r\n[1 of 1] Compiling Main ( pru.hs, pru.o )\r\n\r\nLinking pru ...\r\n\r\n$ ./pru\r\n\r\n0.9999833334166665\r\n\r\n0.0\r\n\r\nI have discovered this problem when a similar test in my hmatrix library failed in 6.12.2. As shown above, it seems that the wrapper only fails on C functions which call back to Haskell.\r\n\r\nLinux 2.6.28-17-generic #58-Ubuntu SMP\r\n\r\nghc-6.12.2-i386-unknown-linux-n.tar.bz2\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4066hSetEncoding only sets the encoding for the read side of a duplex Handle2019-07-07T19:00:51ZSimon MarlowhSetEncoding only sets the encoding for the read side of a duplex HandleFor example, calling `hSetEncoding` on a socket only works for reading, not writing. Can be worked around by calling `socketToHandle` manually to create a `WriteMode` socket.
<details><summary>Trac metadata</summary>
| Trac field ...For example, calling `hSetEncoding` on a socket only works for reading, not writing. Can be worked around by calling `socketToHandle` manually to create a `WriteMode` socket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hSetEncoding only sets the encoding for the read side of a duplex Handle","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.12.3","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For example, calling `hSetEncoding` on a socket only works for reading, not writing. Can be worked around by calling `socketToHandle` manually to create a `WriteMode` socket.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4078hReady and hWaitForInput block under Windows2019-07-07T19:00:47ZtbogdalahReady and hWaitForInput block under WindowsWhile using a Network.Socket converted to a Handle with socketToHandle, calling hReady or hWaitForInput on that handle will block.
This happens within ghci or when compiled with -threaded and executed with "+RTS -N2 -RTS" options.
I've...While using a Network.Socket converted to a Handle with socketToHandle, calling hReady or hWaitForInput on that handle will block.
This happens within ghci or when compiled with -threaded and executed with "+RTS -N2 -RTS" options.
I've attached a simple server.hs file that listens on a port. Once a client connects it loops until hReady returns true - then it will read from the port. Load it in gchi and execute something like:
```
servNumber "11333"
```
I've also attached a quick client.hs module to load in ghci to send data to the port. Load it in ghci and execute something like:
```
s1 <- openServer "localhost" "11333"
write2Server "blash" s1
```
----
Here's the code.
server.hs
```
import Network.Socket
import Control.Concurrent
import System.IO
-- main = servNumber "11333"
servNumber :: String -> IO ()
servNumber port = withSocketsDo $ do
addrInfos <- getAddrInfo
(Just (defaultHints {addrFlags = [AI_PASSIVE]}))
Nothing (Just port)
let serveraddr = head addrInfos
sock <- socket (addrFamily serveraddr) Stream defaultProtocol
bindSocket sock (addrAddress serveraddr)
listen sock 5
procIncoming sock
where
procIncoming :: Socket -> IO ()
procIncoming masterSock = do
(conSock, _) <- accept masterSock
forkIO $ doWork conSock
procIncoming masterSock
doWork :: Socket -> IO ()
doWork conSock = do
h <- socketToHandle conSock ReadWriteMode
hSetBuffering h LineBuffering
loop h
loop :: Handle -> IO ()
loop h = do
putStrLn "Calling hReady."
ready <- hReady h
--ready <- hWaitForInput h 1
if ready
then hGetLine h >>= putStrLn >> loop h
else loop h
```
client.hs
```
import Network.Socket
import Control.Concurrent
import System.IO
openServer :: String -> String -> IO (Handle)
openServer hostname port = withSocketsDo $ do
addrinfos <- getAddrInfo Nothing (Just hostname) (Just port)
let serveraddr = head addrinfos
sock <- socket (addrFamily serveraddr) Stream defaultProtocol
connect sock (addrAddress serveraddr)
h <- socketToHandle sock ReadWriteMode
hSetBuffering h LineBuffering
return h
write2Server :: String -> Handle -> IO ()
write2Server msg h = do
hPutStrLn h msg
hFlush h
closeServer :: Handle -> IO ()
closeServer h = hClose h
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"hReady and h hWaitForInput block under Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["Windows","blocking","hReady","hWaitForInput"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While using a Network.Socket converted to a Handle with socketToHandle, calling hReady or hWaitForInput on that handle will block.\r\n\r\nThis happens within ghci or when compiled with -threaded and executed with \"+RTS -N2 -RTS\" options.\r\n\r\nI've attached a simple server.hs file that listens on a port. Once a client connects it loops until hReady returns true - then it will read from the port. Load it in gchi and execute something like:\r\n\r\n{{{\r\nservNumber \"11333\"\r\n}}}\r\n\r\nI've also attached a quick client.hs module to load in ghci to send data to the port. Load it in ghci and execute something like:\r\n\r\n{{{\r\ns1 <- openServer \"localhost\" \"11333\"\r\nwrite2Server \"blash\" s1\r\n}}}\r\n\r\n----\r\n\r\nHere's the code.\r\n\r\nserver.hs\r\n\r\n{{{\r\nimport Network.Socket\r\nimport Control.Concurrent\r\nimport System.IO\r\n\r\n-- main = servNumber \"11333\"\r\n\r\nservNumber :: String -> IO ()\r\nservNumber port = withSocketsDo $ do\r\n addrInfos <- getAddrInfo \r\n (Just (defaultHints {addrFlags = [AI_PASSIVE]}))\r\n Nothing (Just port)\r\n let serveraddr = head addrInfos\r\n sock <- socket (addrFamily serveraddr) Stream defaultProtocol\r\n bindSocket sock (addrAddress serveraddr)\r\n listen sock 5\r\n procIncoming sock\r\n where\r\n procIncoming :: Socket -> IO ()\r\n procIncoming masterSock = do\r\n (conSock, _) <- accept masterSock\r\n forkIO $ doWork conSock\r\n procIncoming masterSock \r\n\r\n doWork :: Socket -> IO ()\r\n doWork conSock = do\r\n h <- socketToHandle conSock ReadWriteMode\r\n hSetBuffering h LineBuffering\r\n loop h \r\n\r\n loop :: Handle -> IO ()\r\n loop h = do \r\n putStrLn \"Calling hReady.\"\r\n ready <- hReady h\r\n --ready <- hWaitForInput h 1\r\n if ready \r\n then hGetLine h >>= putStrLn >> loop h\r\n else loop h \r\n}}}\r\n\r\nclient.hs\r\n\r\n{{{\r\nimport Network.Socket\r\nimport Control.Concurrent\r\nimport System.IO\r\n\r\n\r\nopenServer :: String -> String -> IO (Handle)\r\nopenServer hostname port = withSocketsDo $ do\r\n addrinfos <- getAddrInfo Nothing (Just hostname) (Just port)\r\n let serveraddr = head addrinfos\r\n sock <- socket (addrFamily serveraddr) Stream defaultProtocol\r\n connect sock (addrAddress serveraddr)\r\n h <- socketToHandle sock ReadWriteMode\r\n hSetBuffering h LineBuffering\r\n return h\r\n\r\nwrite2Server :: String -> Handle -> IO ()\r\nwrite2Server msg h = do\r\n hPutStrLn h msg\r\n hFlush h\r\n\r\ncloseServer :: Handle -> IO ()\r\ncloseServer h = hClose h\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4113canonicalizePath "" returns noise2019-07-07T19:00:31ZbkomuvescanonicalizePath "" returns noiseApparently
```
canonicalizePath ""
```
returns random noise on both Windows and Linux (GHC 6.10.4).
Example session:
```
System.Directory> canonicalizePath ""
"\242\227\&6\STX\NAK"
```
On OSX / GHC 6.10.1 it works correctly (returni...Apparently
```
canonicalizePath ""
```
returns random noise on both Windows and Linux (GHC 6.10.4).
Example session:
```
System.Directory> canonicalizePath ""
"\242\227\&6\STX\NAK"
```
On OSX / GHC 6.10.1 it works correctly (returning the current directory). Linux / GHC 6.8.2 also returns noise.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| 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":"canonicalizePath \"\" returns noise","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["canonicalizePath"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Apparently \r\n\r\n{{{\r\ncanonicalizePath \"\"\r\n}}}\r\n\r\nreturns random noise on both Windows and Linux (GHC 6.10.4).\r\n\r\nExample session:\r\n{{{\r\nSystem.Directory> canonicalizePath \"\"\r\n\"\\242\\227\\&6\\STX\\NAK\"\r\n}}}\r\n\r\nOn OSX / GHC 6.10.1 it works correctly (returning the current directory). Linux / GHC 6.8.2 also returns noise.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4119File buffering isn't flushed at exit2019-07-07T19:00:29ZEyalLotemFile buffering isn't flushed at exitIn C, there's an atexit handler to fflush all FILE\* files.
In most other environments (e.g: Python files), file buffers are flushed in a graceful exit. With GHC 6.12.1, they aren't.
<details><summary>Trac metadata</summary>
| Trac fi...In C, there's an atexit handler to fflush all FILE\* files.
In most other environments (e.g: Python files), file buffers are flushed in a graceful exit. With GHC 6.12.1, they aren't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"File buffering isn't flushed at exit","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["buffers","file"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In C, there's an atexit handler to fflush all FILE* files.\r\n\r\nIn most other environments (e.g: Python files), file buffers are flushed in a graceful exit. With GHC 6.12.1, they aren't.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4130Shared Object of libHShaskell98 Not Found2019-07-07T19:00:27ZpgjShared Object of libHShaskell98 Not FoundThere is dynamic linking problem with the recent GHC-STABLE sources, because during the [tests](http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/9/12.html) (even on [x86_64](http://darcs.haskell.org/ghcBuilder/builder...There is dynamic linking problem with the recent GHC-STABLE sources, because during the [tests](http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/9/12.html) (even on [x86_64](http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/9/12.html)) the output is full of errors like this:
```
/libexec/ld-elf.so.1: Shared object "libHShaskell98-1.0.1.1-ghc6.12.2.YYYYMMDD.so" not found, required by "XXX"
```
Technically, this causes all the dynamically-linked programs using this library to fail the tests:
```
Unexpected failures:
10queens(dyn)
1185(dyn)
1548(dyn)
1679(dyn)
1744(dyn)
1852(dyn)
1861(dyn)
1980(dyn)
2047(dyn)
2080(dyn)
2122(dyn)
2469(dyn)
2594(dyn)
2783(dyn)
2838(dyn)
2910(dyn)
2917a(dyn)
3207(dyn)
3279(dyn)
3429(dyn)
3561(dyn)
3677(dyn)
3816(dyn)
CPUTime001(dyn)
GMapAssoc(dyn)
GMapTop(dyn)
IOError001(dyn)
IOError002(dyn)
OldException001(dyn)
T1624(dyn)
T1735(dyn)
...
T246(dyn)
T2529(dyn)
T2985(dyn)
T3087(dyn)
T3126(dyn)
T3245(dyn)
T3382(dyn)
ThreadDelay001(dyn)
addr001(dyn)
andre_monad(dyn)
andy_cherry(dyn)
arith001(dyn)
arith002(dyn)
arith003(dyn)
arith004(dyn)
arith005(dyn)
arith006(dyn)
arith007(dyn)
arith009(dyn)
arith010(dyn)
arith011(dyn)
arith013(dyn)
arith014(dyn)
arith015(dyn)
arith016(dyn)
arith017(dyn)
arith018(dyn)
arith019(dyn)
arr001(dyn)
arr002(dyn)
arr003(dyn)
arr004(dyn)
arr005(dyn)
arr006(dyn)
arr007(dyn)
arr008(dyn)
arr009(dyn)
arr010(dyn)
arr011(dyn)
arr012(dyn)
arr013(dyn)
arr014(dyn)
arr015(dyn)
arr016(dyn)
arr017(dyn)
arr018(dyn)
arr019(dyn)
arrowrun001(dyn)
arrowrun002(dyn)
arrowrun003(dyn)
arrowrun004(dyn)
barton-mangler-bug(dyn)
bug1010(dyn)
bytestring002(dyn)
bytestring003(dyn)
bytestring006(dyn)
cgrun001(dyn)
cgrun002(dyn)
cgrun003(dyn)
cgrun004(dyn)
cgrun005(dyn)
cgrun006(dyn)
cgrun007(dyn)
cgrun008(dyn)
cgrun009(dyn)
cgrun010(dyn)
cgrun011(dyn)
cgrun012(dyn)
cgrun013(dyn)
cgrun014(dyn)
cgrun015(dyn)
cgrun016(dyn)
cgrun017(dyn)
cgrun018(dyn)
cgrun019(dyn)
cgrun020(dyn)
cgrun021(dyn)
cgrun022(dyn)
cgrun024(dyn)
cgrun026(dyn)
cgrun027(dyn)
cgrun028(dyn)
cgrun031(dyn)
cgrun032(dyn)
cgrun033(dyn)
cgrun034(dyn)
cgrun035(dyn)
cgrun036(dyn)
cgrun037(dyn)
cgrun038(threaded1,dyn)
cgrun039(dyn)
cgrun040(dyn)
cgrun043(dyn)
cgrun044(dyn)
cgrun045(dyn)
cgrun046(dyn)
cgrun047(dyn)
cgrun048(dyn)
cgrun049(dyn)
cgrun050(dyn)
cgrun051(dyn)
cgrun053(dyn)
cgrun054(dyn)
cgrun055(dyn)
cgrun056(dyn)
cgrun058(dyn)
cgrun059(dyn)
cgrun060(dyn)
cgrun061(dyn)
cgrun062(dyn)
cgrun063(dyn)
char001(dyn)
char002(dyn)
cholewo-eval(dyn)
church(dyn)
conc001(dyn)
conc002(dyn)
conc003(dyn)
conc004(dyn)
conc006(dyn)
conc007(dyn)
conc008(dyn)
conc009(dyn)
conc010(dyn)
conc012(dyn)
conc013(dyn)
conc014(dyn)
conc015(dyn)
conc016(dyn)
conc017(dyn)
conc018(dyn)
conc019(dyn)
conc020(dyn)
conc021(dyn)
conc022(dyn)
conc023(dyn)
conc024(dyn)
conc025(dyn)
conc026(dyn)
conc027(dyn)
conc028(dyn)
conc029(dyn)
conc030(dyn)
conc031(dyn)
conc032(dyn)
conc033(dyn)
conc034(dyn)
conc035(dyn)
conc036(dyn)
conc039(dyn)
conc040(dyn)
conc041(dyn)
conc042(dyn)
conc043(dyn)
conc044(dyn)
conc045(dyn)
conc051(dyn)
conc058(dyn)
...
conc064(dyn)
conc065(dyn)
conc066(dyn)
conc067(dyn)
conc068(dyn)
concio002(dyn)
...
concprog003(dyn)
countReaders001(dyn)
cvh_unboxing(dyn)
decodingerror001(dyn)
derefnull(profc,dyn,profthreaded)
divbyzero(profc,dyn,profthreaded)
drvrun-foldable1(dyn)
drvrun-functor1(dyn)
drvrun001(dyn)
drvrun002(dyn)
drvrun003(dyn)
drvrun004(dyn)
drvrun005(dyn)
drvrun006(dyn)
drvrun007(dyn)
drvrun008(dyn)
drvrun009(dyn)
drvrun010(dyn)
drvrun011(dyn)
drvrun012(dyn)
drvrun013(dyn)
drvrun014(dyn)
drvrun015(dyn)
drvrun016(dyn)
drvrun017(dyn)
drvrun018(dyn)
drvrun019(dyn)
drvrun020(dyn)
drvrun021(dyn)
drvrun022(dyn)
dsrun001(dyn)
dsrun002(dyn)
dsrun003(dyn)
dsrun004(dyn)
dsrun005(dyn)
dsrun006(dyn)
dsrun007(dyn)
dsrun008(dyn)
dsrun009(dyn)
dsrun010(dyn)
dsrun011(dyn)
dsrun012(dyn)
dsrun013(dyn)
dsrun014(dyn)
dsrun016(dyn)
dsrun017(dyn)
dsrun018(dyn)
dsrun019(dyn)
dsrun020(dyn)
dsrun021(dyn)
dsrun022(dyn)
dsrun023(dyn)
dynHelloWorld(dyn)
dynamic001(dyn)
echo001(dyn)
encoding001(dyn)
enum01(dyn)
enum02(dyn)
enum03(dyn)
exceptions001(dyn)
exceptionsrun001(dyn)
exceptionsrun002(dyn)
exitWith001(dyn)
expfloat(dyn)
fast2haskell(dyn)
...
fed001(dyn)
ffi001(dyn)
ffi002(dyn)
ffi003(dyn)
ffi006(dyn)
ffi007(dyn)
ffi008(dyn)
ffi010(dyn)
ffi011(dyn)
ffi013(dyn)
ffi015(dyn)
ffi016(dyn)
ffi017(dyn)
ffi018(dyn)
ffi019(dyn)
ffi020(dyn)
ffi021(dyn,profthreaded)
fileStatus(dyn)
fileexist01(dyn)
finalization001(dyn)
forkprocess01(dyn)
fptr01(dyn)
fptrfail01(dyn)
fun_insts(dyn)
genericNegative001(dyn)
getArgs001(dyn)
getEnv001(dyn)
hClose001(dyn)
hClose002(dyn)
hClose003(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)
hDuplicateTo001(dyn)
hFileSize001(dyn)
hFileSize002(dyn)
hFlush001(dyn)
hGetBuf001(dyn)
hGetBuf002(dyn)
hGetBuf003(dyn)
hGetBuffering001(dyn)
hGetChar001(dyn)
hGetLine001(dyn)
hGetLine002(dyn)
hGetLine003(dyn)
hGetPosn001(dyn)
hIsEOF001(dyn)
hIsEOF002(dyn)
hPutBuf001(dyn)
hPutBuf002(dyn)
hReady001(dyn)
hReady002(ghci,dyn)
hSeek001(dyn)
hSeek002(dyn)
hSeek003(dyn)
hSeek004(dyn)
hSetBuffering002(dyn)
hSetBuffering003(dyn)
hSetBuffering004(dyn)
hSetEncoding001(dyn)
hTell001(dyn)
hTell002(dyn)
hash001(dyn)
integerBits(dyn)
integerConversions(dyn)
ioeGetErrorString001(dyn)
ioeGetFileName001(dyn)
ioeGetHandle001(dyn)
ioref001(dyn)
isEOF001(dyn)
ix001(dyn)
jl_defaults(dyn)
joao-circular(profc,dyn)
jq_readsPrec(dyn)
jtod_circint(dyn)
jules_xref(dyn)
jules_xref2(dyn)
launchbury(dyn)
length001(dyn)
lennart_range(dyn)
lex(dyn)
lexNum(dyn)
life_space_leak(dyn,profthreaded)
list001(dyn)
list002(dyn)
list003(dyn)
memo001(dyn)
memo002(dyn)
misc001(dyn)
newline001(dyn)
north_array(dyn)
num001(dyn)
num002(dyn)
num003(dyn)
num004(dyn)
num005(dyn)
num006(dyn)
num007(dyn)
num008(dyn)
num009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)
num010(dyn)
numrun009(dyn)
numrun010(dyn)
numrun011(dyn)
numrun012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)
numrun013(dyn)
numrun014(dyn)
openFile001(dyn)
openFile002(dyn)
openFile003(dyn)
openFile004(dyn)
openFile005(dyn)
openFile006(dyn)
openFile007(dyn)
openFile008(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)
openTempFile001(dyn)
performGC001(dyn)
putStr001(dyn)
rand001(dyn)
ratio001(dyn)
readFile001(dyn)
readLitChar(dyn)
readRun001(dyn)
readRun002(dyn)
readRun003(dyn)
readRun004(dyn)
reads001(dyn)
readwrite001(dyn)
readwrite002(dyn)
readwrite003(dyn)
record_upd(dyn)
resourceLimit(dyn)
rittri(dyn)
sanders_array(dyn)
seward-space-leak(dyn)
show001(dyn)
showDouble(dyn)
signals001(dyn)
signals002(dyn)
signals004(dyn)
space_leak_001(dyn)
stableptr001(dyn)
stableptr003(dyn)
stableptr004(dyn)
stableptr005(dyn)
stack001(dyn)
stack002(dyn)
strict_anns(dyn)
system001(dyn)
take001(dyn)
tcrun001(dyn)
tcrun002(dyn)
tcrun003(dyn)
tcrun004(dyn)
tcrun005(dyn)
tcrun006(dyn)
tcrun007(dyn)
tcrun008(dyn)
tcrun009(dyn)
tcrun010(dyn)
tcrun011(dyn)
tcrun012(dyn)
tcrun013(dyn)
tcrun014(dyn)
tcrun015(dyn)
tcrun016(dyn)
tcrun017(dyn)
tcrun018(dyn)
tcrun019(dyn)
tcrun020(dyn)
tcrun021(dyn)
tcrun022(dyn)
tcrun023(dyn)
tcrun024(dyn)
tcrun025(dyn)
tcrun027(dyn)
tcrun028(dyn)
tcrun029(dyn)
tcrun030(dyn)
tcrun031(dyn)
tcrun032(dyn)
tcrun033(dyn)
tcrun034(dyn)
tcrun035(dyn)
tcrun036(dyn)
tcrun037(dyn)
tcrun038(dyn)
tcrun039(dyn)
tcrun040(dyn)
tcrun041(dyn)
tcrun042(dyn)
...
testeq2(dyn)
text001(dyn)
thurston-modular-arith(dyn)
time002(dyn)
time003(dyn)
time004(dyn)
trace001(dyn)
tup001(dyn)
typecheck.testeq1(dyn)
unicode001(dyn)
unicode002(threaded2,dyn)
user001(dyn)
utf8_024(dyn)
weak001(dyn)
```
Note that it is not present in GHC-HEAD (see the tests on [x86](http://darcs.haskell.org/ghcBuilder/builders/pgj/57/12.html) and [x86_64](http://darcs.haskell.org/ghcBuilder/builders/pgj2/55/12.html)). I am not sure that it is FreeBSD-specific, but it seems it has happened on FreeBSD only so far.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | pgj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Shared Object of libHShaskell98 Not Found","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["pgj"],"type":"Bug","description":"There is dynamic linking problem with the recent GHC-STABLE sources, because during the [http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/9/12.html tests] (even on [http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/9/12.html x86_64]) the output is full of errors like this:\r\n\r\n{{{\r\n/libexec/ld-elf.so.1: Shared object \"libHShaskell98-1.0.1.1-ghc6.12.2.YYYYMMDD.so\" not found, required by \"XXX\"\r\n}}}\r\n\r\nTechnically, this causes all the dynamically-linked programs using this library to fail the tests:\r\n\r\n{{{\r\nUnexpected failures:\r\n10queens(dyn)\r\n1185(dyn)\r\n1548(dyn)\r\n1679(dyn)\r\n1744(dyn)\r\n1852(dyn)\r\n1861(dyn)\r\n1980(dyn)\r\n2047(dyn)\r\n2080(dyn)\r\n2122(dyn)\r\n2469(dyn)\r\n2594(dyn)\r\n2783(dyn)\r\n2838(dyn)\r\n2910(dyn)\r\n2917a(dyn)\r\n3207(dyn)\r\n3279(dyn)\r\n3429(dyn)\r\n3561(dyn)\r\n3677(dyn)\r\n3816(dyn)\r\nCPUTime001(dyn)\r\nGMapAssoc(dyn)\r\nGMapTop(dyn)\r\nIOError001(dyn)\r\nIOError002(dyn)\r\nOldException001(dyn)\r\nT1624(dyn)\r\nT1735(dyn)\r\n...\r\nT246(dyn)\r\nT2529(dyn)\r\nT2985(dyn)\r\nT3087(dyn)\r\nT3126(dyn)\r\nT3245(dyn)\r\nT3382(dyn)\r\nThreadDelay001(dyn)\r\naddr001(dyn)\r\nandre_monad(dyn)\r\nandy_cherry(dyn)\r\narith001(dyn)\r\narith002(dyn)\r\narith003(dyn)\r\narith004(dyn)\r\narith005(dyn)\r\narith006(dyn)\r\narith007(dyn)\r\narith009(dyn)\r\narith010(dyn)\r\narith011(dyn)\r\narith013(dyn)\r\narith014(dyn)\r\narith015(dyn)\r\narith016(dyn)\r\narith017(dyn)\r\narith018(dyn)\r\narith019(dyn)\r\narr001(dyn)\r\narr002(dyn)\r\narr003(dyn)\r\narr004(dyn)\r\narr005(dyn)\r\narr006(dyn)\r\narr007(dyn)\r\narr008(dyn)\r\narr009(dyn)\r\narr010(dyn)\r\narr011(dyn)\r\narr012(dyn)\r\narr013(dyn)\r\narr014(dyn)\r\narr015(dyn)\r\narr016(dyn)\r\narr017(dyn)\r\narr018(dyn)\r\narr019(dyn)\r\narrowrun001(dyn)\r\narrowrun002(dyn)\r\narrowrun003(dyn)\r\narrowrun004(dyn)\r\nbarton-mangler-bug(dyn)\r\nbug1010(dyn)\r\nbytestring002(dyn)\r\nbytestring003(dyn)\r\nbytestring006(dyn)\r\ncgrun001(dyn)\r\ncgrun002(dyn)\r\ncgrun003(dyn)\r\ncgrun004(dyn)\r\ncgrun005(dyn)\r\ncgrun006(dyn)\r\ncgrun007(dyn)\r\ncgrun008(dyn)\r\ncgrun009(dyn)\r\ncgrun010(dyn)\r\ncgrun011(dyn)\r\ncgrun012(dyn)\r\ncgrun013(dyn)\r\ncgrun014(dyn)\r\ncgrun015(dyn)\r\ncgrun016(dyn)\r\ncgrun017(dyn)\r\ncgrun018(dyn)\r\ncgrun019(dyn)\r\ncgrun020(dyn)\r\ncgrun021(dyn)\r\ncgrun022(dyn)\r\ncgrun024(dyn)\r\ncgrun026(dyn)\r\ncgrun027(dyn)\r\ncgrun028(dyn)\r\ncgrun031(dyn)\r\ncgrun032(dyn)\r\ncgrun033(dyn)\r\ncgrun034(dyn)\r\ncgrun035(dyn)\r\ncgrun036(dyn)\r\ncgrun037(dyn)\r\ncgrun038(threaded1,dyn)\r\ncgrun039(dyn)\r\ncgrun040(dyn)\r\ncgrun043(dyn)\r\ncgrun044(dyn)\r\ncgrun045(dyn)\r\ncgrun046(dyn)\r\ncgrun047(dyn)\r\ncgrun048(dyn)\r\ncgrun049(dyn)\r\ncgrun050(dyn)\r\ncgrun051(dyn)\r\ncgrun053(dyn)\r\ncgrun054(dyn)\r\ncgrun055(dyn)\r\ncgrun056(dyn)\r\ncgrun058(dyn)\r\ncgrun059(dyn)\r\ncgrun060(dyn)\r\ncgrun061(dyn)\r\ncgrun062(dyn)\r\ncgrun063(dyn)\r\nchar001(dyn)\r\nchar002(dyn)\r\ncholewo-eval(dyn)\r\nchurch(dyn)\r\nconc001(dyn)\r\nconc002(dyn)\r\nconc003(dyn)\r\nconc004(dyn)\r\nconc006(dyn)\r\nconc007(dyn)\r\nconc008(dyn)\r\nconc009(dyn)\r\nconc010(dyn)\r\nconc012(dyn)\r\nconc013(dyn)\r\nconc014(dyn)\r\nconc015(dyn)\r\nconc016(dyn)\r\nconc017(dyn)\r\nconc018(dyn)\r\nconc019(dyn)\r\nconc020(dyn)\r\nconc021(dyn)\r\nconc022(dyn)\r\nconc023(dyn)\r\nconc024(dyn)\r\nconc025(dyn)\r\nconc026(dyn)\r\nconc027(dyn)\r\nconc028(dyn)\r\nconc029(dyn)\r\nconc030(dyn)\r\nconc031(dyn)\r\nconc032(dyn)\r\nconc033(dyn)\r\nconc034(dyn)\r\nconc035(dyn)\r\nconc036(dyn)\r\nconc039(dyn)\r\nconc040(dyn)\r\nconc041(dyn)\r\nconc042(dyn)\r\nconc043(dyn)\r\nconc044(dyn)\r\nconc045(dyn)\r\nconc051(dyn)\r\nconc058(dyn)\r\n...\r\nconc064(dyn)\r\nconc065(dyn)\r\nconc066(dyn)\r\nconc067(dyn)\r\nconc068(dyn)\r\nconcio002(dyn)\r\n...\r\nconcprog003(dyn)\r\ncountReaders001(dyn)\r\ncvh_unboxing(dyn)\r\ndecodingerror001(dyn)\r\nderefnull(profc,dyn,profthreaded)\r\ndivbyzero(profc,dyn,profthreaded)\r\ndrvrun-foldable1(dyn)\r\ndrvrun-functor1(dyn)\r\ndrvrun001(dyn)\r\ndrvrun002(dyn)\r\ndrvrun003(dyn)\r\ndrvrun004(dyn)\r\ndrvrun005(dyn)\r\ndrvrun006(dyn)\r\ndrvrun007(dyn)\r\ndrvrun008(dyn)\r\ndrvrun009(dyn)\r\ndrvrun010(dyn)\r\ndrvrun011(dyn)\r\ndrvrun012(dyn)\r\ndrvrun013(dyn)\r\ndrvrun014(dyn)\r\ndrvrun015(dyn)\r\ndrvrun016(dyn)\r\ndrvrun017(dyn)\r\ndrvrun018(dyn)\r\ndrvrun019(dyn)\r\ndrvrun020(dyn)\r\ndrvrun021(dyn)\r\ndrvrun022(dyn)\r\ndsrun001(dyn)\r\ndsrun002(dyn)\r\ndsrun003(dyn)\r\ndsrun004(dyn)\r\ndsrun005(dyn)\r\ndsrun006(dyn)\r\ndsrun007(dyn)\r\ndsrun008(dyn)\r\ndsrun009(dyn)\r\ndsrun010(dyn)\r\ndsrun011(dyn)\r\ndsrun012(dyn)\r\ndsrun013(dyn)\r\ndsrun014(dyn)\r\ndsrun016(dyn)\r\ndsrun017(dyn)\r\ndsrun018(dyn)\r\ndsrun019(dyn)\r\ndsrun020(dyn)\r\ndsrun021(dyn)\r\ndsrun022(dyn)\r\ndsrun023(dyn)\r\ndynHelloWorld(dyn)\r\ndynamic001(dyn)\r\necho001(dyn)\r\nencoding001(dyn)\r\nenum01(dyn)\r\nenum02(dyn)\r\nenum03(dyn)\r\nexceptions001(dyn)\r\nexceptionsrun001(dyn)\r\nexceptionsrun002(dyn)\r\nexitWith001(dyn)\r\nexpfloat(dyn)\r\nfast2haskell(dyn)\r\n...\r\nfed001(dyn)\r\nffi001(dyn)\r\nffi002(dyn)\r\nffi003(dyn)\r\nffi006(dyn)\r\nffi007(dyn)\r\nffi008(dyn)\r\nffi010(dyn)\r\nffi011(dyn)\r\nffi013(dyn)\r\nffi015(dyn)\r\nffi016(dyn)\r\nffi017(dyn)\r\nffi018(dyn)\r\nffi019(dyn)\r\nffi020(dyn)\r\nffi021(dyn,profthreaded)\r\nfileStatus(dyn)\r\nfileexist01(dyn)\r\nfinalization001(dyn)\r\nforkprocess01(dyn)\r\nfptr01(dyn)\r\nfptrfail01(dyn)\r\nfun_insts(dyn)\r\ngenericNegative001(dyn)\r\ngetArgs001(dyn)\r\ngetEnv001(dyn)\r\nhClose001(dyn)\r\nhClose002(dyn)\r\nhClose003(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)\r\nhDuplicateTo001(dyn)\r\nhFileSize001(dyn)\r\nhFileSize002(dyn)\r\nhFlush001(dyn)\r\nhGetBuf001(dyn)\r\nhGetBuf002(dyn)\r\nhGetBuf003(dyn)\r\nhGetBuffering001(dyn)\r\nhGetChar001(dyn)\r\nhGetLine001(dyn)\r\nhGetLine002(dyn)\r\nhGetLine003(dyn)\r\nhGetPosn001(dyn)\r\nhIsEOF001(dyn)\r\nhIsEOF002(dyn)\r\nhPutBuf001(dyn)\r\nhPutBuf002(dyn)\r\nhReady001(dyn)\r\nhReady002(ghci,dyn)\r\nhSeek001(dyn)\r\nhSeek002(dyn)\r\nhSeek003(dyn)\r\nhSeek004(dyn)\r\nhSetBuffering002(dyn)\r\nhSetBuffering003(dyn)\r\nhSetBuffering004(dyn)\r\nhSetEncoding001(dyn)\r\nhTell001(dyn)\r\nhTell002(dyn)\r\nhash001(dyn)\r\nintegerBits(dyn)\r\nintegerConversions(dyn)\r\nioeGetErrorString001(dyn)\r\nioeGetFileName001(dyn)\r\nioeGetHandle001(dyn)\r\nioref001(dyn)\r\nisEOF001(dyn)\r\nix001(dyn)\r\njl_defaults(dyn)\r\njoao-circular(profc,dyn)\r\njq_readsPrec(dyn)\r\njtod_circint(dyn)\r\njules_xref(dyn)\r\njules_xref2(dyn)\r\nlaunchbury(dyn)\r\nlength001(dyn)\r\nlennart_range(dyn)\r\nlex(dyn)\r\nlexNum(dyn)\r\nlife_space_leak(dyn,profthreaded)\r\nlist001(dyn)\r\nlist002(dyn)\r\nlist003(dyn)\r\nmemo001(dyn)\r\nmemo002(dyn)\r\nmisc001(dyn)\r\nnewline001(dyn)\r\nnorth_array(dyn)\r\nnum001(dyn)\r\nnum002(dyn)\r\nnum003(dyn)\r\nnum004(dyn)\r\nnum005(dyn)\r\nnum006(dyn)\r\nnum007(dyn)\r\nnum008(dyn)\r\nnum009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)\r\nnum010(dyn)\r\nnumrun009(dyn)\r\nnumrun010(dyn)\r\nnumrun011(dyn)\r\nnumrun012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)\r\nnumrun013(dyn)\r\nnumrun014(dyn)\r\nopenFile001(dyn)\r\nopenFile002(dyn)\r\nopenFile003(dyn)\r\nopenFile004(dyn)\r\nopenFile005(dyn)\r\nopenFile006(dyn)\r\nopenFile007(dyn)\r\nopenFile008(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded)\r\nopenTempFile001(dyn)\r\nperformGC001(dyn)\r\nputStr001(dyn)\r\nrand001(dyn)\r\nratio001(dyn)\r\nreadFile001(dyn)\r\nreadLitChar(dyn)\r\nreadRun001(dyn)\r\nreadRun002(dyn)\r\nreadRun003(dyn)\r\nreadRun004(dyn)\r\nreads001(dyn)\r\nreadwrite001(dyn)\r\nreadwrite002(dyn)\r\nreadwrite003(dyn)\r\nrecord_upd(dyn)\r\nresourceLimit(dyn)\r\nrittri(dyn)\r\nsanders_array(dyn)\r\nseward-space-leak(dyn)\r\nshow001(dyn)\r\nshowDouble(dyn)\r\nsignals001(dyn)\r\nsignals002(dyn)\r\nsignals004(dyn)\r\nspace_leak_001(dyn)\r\nstableptr001(dyn)\r\nstableptr003(dyn)\r\nstableptr004(dyn)\r\nstableptr005(dyn)\r\nstack001(dyn)\r\nstack002(dyn)\r\nstrict_anns(dyn)\r\nsystem001(dyn)\r\ntake001(dyn)\r\ntcrun001(dyn)\r\ntcrun002(dyn)\r\ntcrun003(dyn)\r\ntcrun004(dyn)\r\ntcrun005(dyn)\r\ntcrun006(dyn)\r\ntcrun007(dyn)\r\ntcrun008(dyn)\r\ntcrun009(dyn)\r\ntcrun010(dyn)\r\ntcrun011(dyn)\r\ntcrun012(dyn)\r\ntcrun013(dyn)\r\ntcrun014(dyn)\r\ntcrun015(dyn)\r\ntcrun016(dyn)\r\ntcrun017(dyn)\r\ntcrun018(dyn)\r\ntcrun019(dyn)\r\ntcrun020(dyn)\r\ntcrun021(dyn)\r\ntcrun022(dyn)\r\ntcrun023(dyn)\r\ntcrun024(dyn)\r\ntcrun025(dyn)\r\ntcrun027(dyn)\r\ntcrun028(dyn)\r\ntcrun029(dyn)\r\ntcrun030(dyn)\r\ntcrun031(dyn)\r\ntcrun032(dyn)\r\ntcrun033(dyn)\r\ntcrun034(dyn)\r\ntcrun035(dyn)\r\ntcrun036(dyn)\r\ntcrun037(dyn)\r\ntcrun038(dyn)\r\ntcrun039(dyn)\r\ntcrun040(dyn)\r\ntcrun041(dyn)\r\ntcrun042(dyn)\r\n...\r\ntesteq2(dyn)\r\ntext001(dyn)\r\nthurston-modular-arith(dyn)\r\ntime002(dyn)\r\ntime003(dyn)\r\ntime004(dyn)\r\ntrace001(dyn)\r\ntup001(dyn)\r\ntypecheck.testeq1(dyn)\r\nunicode001(dyn)\r\nunicode002(threaded2,dyn)\r\nuser001(dyn)\r\nutf8_024(dyn)\r\nweak001(dyn)\r\n}}}\r\n\r\nNote that it is not present in GHC-HEAD (see the tests on [http://darcs.haskell.org/ghcBuilder/builders/pgj/57/12.html x86] and [http://darcs.haskell.org/ghcBuilder/builders/pgj2/55/12.html x86_64]). I am not sure that it is FreeBSD-specific, but it seems it has happened on FreeBSD only so far.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4154Deadlock in Chan module2019-07-07T19:00:22ZNeil MitchellDeadlock in Chan moduleThe following program:
```hs
module Main where
import Control.Concurrent
main :: IO ()
main = do
todo <- newChan
forkIO $ readChan todo
putStrLn "Before isEmptyChan"
b <- isEmptyChan todo
putStrLn "After isEmptyCha...The following program:
```hs
module Main where
import Control.Concurrent
main :: IO ()
main = do
todo <- newChan
forkIO $ readChan todo
putStrLn "Before isEmptyChan"
b <- isEmptyChan todo
putStrLn "After isEmptyChan"
writeChan todo ()
```
Gives the output:
```
$ ghc --make Main.hs -threaded && ./Main.exe
Before isEmptyChan
Main.exe: thread blocked indefinitely in an MVar operation
```
I think that's a bug. Note that if the `putStrLn` statements are removed then it works, but I think that's because the printing introduces a delay that lets the other thread run.8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/4198waitForProcess fails with "Bad file descriptor"2019-07-07T19:00:08ZyugrwaitForProcess fails with "Bad file descriptor"I am running this small sample program:
```
int main() { return -1; }
```
from this Haskell code (both from ghci and compiled):
```
import System.Process
main = system "a.exe" >> putStrLn "This is not printed"
```
and get this error
...I am running this small sample program:
```
int main() { return -1; }
```
from this Haskell code (both from ghci and compiled):
```
import System.Process
main = system "a.exe" >> putStrLn "This is not printed"
```
and get this error
```
tmp.exe: waitForProcess: invalid argument (Bad file descriptor)
```
I guess there is a runtime error inside system-call which crashes execution.
I am on Windows 7, ghc 6.12.1. I tried both Cygwin g++ and MSVS cl C++ compilers.
One side question: is there any other way to run external program?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"waitForProcess fails with \"Bad file descriptor\"","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["waitForProcess"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I am running this small sample program:\r\n{{{\r\nint main() { return -1; }\r\n}}}\r\nfrom this Haskell code (both from ghci and compiled):\r\n{{{\r\nimport System.Process\r\nmain = system \"a.exe\" >> putStrLn \"This is not printed\"\r\n}}}\r\nand get this error\r\n{{{\r\ntmp.exe: waitForProcess: invalid argument (Bad file descriptor)\r\n}}}\r\n\r\nI guess there is a runtime error inside system-call which crashes execution.\r\n\r\nI am on Windows 7, ghc 6.12.1. I tried both Cygwin g++ and MSVS cl C++ compilers.\r\n\r\nOne side question: is there any other way to run external program?","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4215canonicalizePath behaves strangely with paths that do not exist2019-07-07T19:00:04ZcreswickcanonicalizePath behaves strangely with paths that do not existThe behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior woul...The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.
This is complicated by differing behaviors of the underlying realpath(char\*, char\*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:
- $HOME/tmp/foo is a file.
- $HOME/tmp/bar is a directory.
- $HOME/tmp/baz does not exist.
Linux:
```
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/foo/subdir"
"/home/creswick/tmp/foo"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/bar/subdir"
"/home/creswick/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/baz/subdir"
"/home/creswick/tmp/baz"
```
OS-X:
```
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/foo/subdir"
"/Users/hudson/tmp/foo/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/bar/subdir"
"/Users/hudson/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/baz/subdir"
"/Users/hudson/tmp/baz"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"canonicalizePath behaves strangely with paths that do not exist","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.\r\n\r\nThis is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:\r\n\r\n * $HOME/tmp/foo is a file.\r\n * $HOME/tmp/bar is a directory.\r\n * $HOME/tmp/baz does not exist.\r\n\r\nLinux:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/foo/subdir\"\r\n\"/home/creswick/tmp/foo\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/bar/subdir\"\r\n\"/home/creswick/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/baz/subdir\"\r\n\"/home/creswick/tmp/baz\"\r\n}}}\r\n\r\nOS-X:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/foo/subdir\" \r\n\"/Users/hudson/tmp/foo/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/bar/subdir\"\r\n\"/Users/hudson/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/baz/subdir\"\r\n\"/Users/hudson/tmp/baz\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/4228atanh (-1) returns NaN instead of -Infinity2019-07-07T18:59:59Zsbroadheadatanh (-1) returns NaN instead of -InfinityAccording to the man page for libc's atanh:
If x is +1 or -1, a pole error occurs, and the functions return HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with the mathematically correct sign.
`atanh 1` correctly returns Infinity, bu...According to the man page for libc's atanh:
If x is +1 or -1, a pole error occurs, and the functions return HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with the mathematically correct sign.
`atanh 1` correctly returns Infinity, but `atanh (-1)` returns NaN instead of -Infinity. A C program compiled on the same system gives the correct result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"atanh (-1) returns NaN instead of -Infinity","status":"New","operating_system":"MacOS X","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"According to the man page for libc's atanh:\r\n\r\nIf x is +1 or -1, a pole error occurs, and the functions return HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with the mathematically correct sign.\r\n\r\n{{{atanh 1}}} correctly returns Infinity, but {{{atanh (-1)}}} returns NaN instead of -Infinity. A C program compiled on the same system gives the correct result.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4241Optimization causes HUnit to behave incorrectly2019-07-07T18:59:53Zbeej175560Optimization causes HUnit to behave incorrectlyWhen I build the following program with "ghc -O2 --make ...", the unit test passes. I expect the test to fail because 1 does not equal 2. Compiling without optimization results in correct behavior.
I'm not sure if this is a compiler bug...When I build the following program with "ghc -O2 --make ...", the unit test passes. I expect the test to fail because 1 does not equal 2. Compiling without optimization results in correct behavior.
I'm not sure if this is a compiler bug but I'm filing it as such because of the dependence on optimization. I'm running ghc on Mac OS 10.6.3 installed from the downloaded file haskell-platform-2010.1.0.1-i386.dmg. The ghc version is 6.12.1.
import Test.HUnit
tests = test \[ test \[1 \~?= 2\] \]
main = runTestTT tests
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Optimization causes HUnit to behave incorrectly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I build the following program with \"ghc -O2 --make ...\", the unit test passes. I expect the test to fail because 1 does not equal 2. Compiling without optimization results in correct behavior.\r\n\r\nI'm not sure if this is a compiler bug but I'm filing it as such because of the dependence on optimization. I'm running ghc on Mac OS 10.6.3 installed from the downloaded file haskell-platform-2010.1.0.1-i386.dmg. The ghc version is 6.12.1.\r\n\r\nimport Test.HUnit\r\n\r\ntests = test [ test [1 ~?= 2] ]\r\n\r\nmain = runTestTT tests\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4247getCPUTime on x86_64 Mac OS X 10.62019-07-07T18:59:51ZquarkgetCPUTime on x86_64 Mac OS X 10.6I have GHC 6.10.4 installed on a recent Mac Mini, which is running a 32-bit kernel (Snow Leopard, 10.6) but has 64-bit GHC installed, using MacPorts. I've compiled a very large commercial product with this installation (with FFI etc) and...I have GHC 6.10.4 installed on a recent Mac Mini, which is running a 32-bit kernel (Snow Leopard, 10.6) but has 64-bit GHC installed, using MacPorts. I've compiled a very large commercial product with this installation (with FFI etc) and the product's testsuite passes, so I'm fairly confident that GHC is working ... except that "getCPUTime" is giving bogus values.
This simple program:
```
import CPUTime
fn = do t <- getCPUTime
putStrLn ("t = " ++ show t)
fn
main :: IO ()
main = fn
```
ought to produce increasing values of "t". However, the output jumps around wildly, from 10\^22\^, to 10\^24\^, to 10\^15\^.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| 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":"getCPUTime on x86_64 Mac OS X 10.6","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have GHC 6.10.4 installed on a recent Mac Mini, which is running a 32-bit kernel (Snow Leopard, 10.6) but has 64-bit GHC installed, using MacPorts. I've compiled a very large commercial product with this installation (with FFI etc) and the product's testsuite passes, so I'm fairly confident that GHC is working ... except that \"getCPUTime\" is giving bogus values.\r\n\r\nThis simple program:\r\n{{{\r\nimport CPUTime\r\nfn = do t <- getCPUTime\r\n putStrLn (\"t = \" ++ show t)\r\n fn\r\nmain :: IO ()\r\nmain = fn\r\n}}}\r\nought to produce increasing values of \"t\". However, the output jumps around wildly, from 10^22^, to 10^24^, to 10^15^.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4251GHC hangs during Network.HTTP.simpleHTTP on Windows XP SP3, Windows 72019-07-07T18:59:50Zbalta2arGHC hangs during Network.HTTP.simpleHTTP on Windows XP SP3, Windows 7After executing:
`simpleHTTP (getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")`
GHC hangs and consumes all the CPU resources (CPU load rises to 100%).
Sample log:
```
C:\>ghci -v -dcore-lint
GHCi...After executing:
`simpleHTTP (getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")`
GHC hangs and consumes all the CPU resources (CPU load rises to 100%).
Sample log:
```
C:\>ghci -v -dcore-lint
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.10.4
Using binary package database: C:\PROGRA~1\HASKEL~1\201020~1.0\lib\package.conf.d\package.cache
Using binary package database: C:\Documents and Settings\User\Application Data\ghc\i386-mingw32-6.12.3\package.conf.d\package.cache
hiding package regex-posix-0.94.2 to avoid conflict with later version regex-posix-0.94.4
hiding package base-3.0.3.2 to avoid conflict with later version base-4.2.0.2
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-2feb0cb38f65a4827135ada88c34f3ef
wired-in package integer-gmp mapped to integer-gmp-0.2.0.1-72436e28c79d056c87cc0d2d2f9f3773
wired-in package base mapped to base-4.2.0.2-0d1804f62045e52b2e806996d84f5318
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-1.0.1.1-b5196101fd7a8c42a8d53bd8033d6765
wired-in package template-haskell mapped to template-haskell-2.4.0.1-401621dedd4a5f07bfd8630247358bf5
wired-in package dph-seq mapped to dph-seq-0.4.0-be069f0bb710922a6ddd4ed2b91e3a6c
wired-in package dph-par mapped to dph-par-0.4.0-b31a0ce10b7c92126978fcc929077ad6
Hsc static flags: -static
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :module +Network.HTTP
Prelude Network.HTTP> simpleHTTP (getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package network-2.2.1.7 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package bytestring-0.9.1.7 ... linking ... done.
Loading package Win32-2.2.0.2 ... linking ... done.
Loading package array-0.3.0.1 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.5 ... linking ... done.
Loading package HTTP-4000.0.9 ... linking ... done.
*GHC hangs here*
```
I'm using Windows XP SP3, Haskell Platform 2010.2.0.0. No firewall or proxy restrictions.
The bug was also reported here:
[http://groups.google.com/group/haskell-cafe/browse_thread/thread/4e4a7e5eb92d1b81/48300428c7c10a57?lnk=gst&q=HTTP+package\#48300428c7c10a57](http://groups.google.com/group/haskell-cafe/browse_thread/thread/4e4a7e5eb92d1b81/48300428c7c10a57?lnk=gst&q=HTTP+package#48300428c7c10a57)
There's a file in attachment with Wireshark's capture during the sample execution.
Note the same sample on ghc 6.12.1, haskell-network 2.2.1.7-3 on ArchLinux works just fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"GHC hangs during Network.HTTP.simpleHTTP on Windows XP SP3, Windows 7","status":"New","operating_system":"Windows","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["hang,","simplehttp"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"After executing:\r\n\r\n{{{simpleHTTP (getRequest \"http://maps.google.com/maps/api/geocode/json?address=London&sensor=false\")}}}\r\n\r\nGHC hangs and consumes all the CPU resources (CPU load rises to 100%).\r\n\r\nSample log:\r\n{{{\r\nC:\\>ghci -v -dcore-lint\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nGlasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.10.4\r\nUsing binary package database: C:\\PROGRA~1\\HASKEL~1\\201020~1.0\\lib\\package.conf.d\\package.cache\r\nUsing binary package database: C:\\Documents and Settings\\User\\Application Data\\ghc\\i386-mingw32-6.12.3\\package.conf.d\\package.cache\r\nhiding package regex-posix-0.94.2 to avoid conflict with later version regex-posix-0.94.4\r\nhiding package base-3.0.3.2 to avoid conflict with later version base-4.2.0.2\r\nwired-in package ghc-prim mapped to ghc-prim-0.2.0.0-2feb0cb38f65a4827135ada88c34f3ef\r\nwired-in package integer-gmp mapped to integer-gmp-0.2.0.1-72436e28c79d056c87cc0d2d2f9f3773\r\nwired-in package base mapped to base-4.2.0.2-0d1804f62045e52b2e806996d84f5318\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package haskell98 mapped to haskell98-1.0.1.1-b5196101fd7a8c42a8d53bd8033d6765\r\nwired-in package template-haskell mapped to template-haskell-2.4.0.1-401621dedd4a5f07bfd8630247358bf5\r\nwired-in package dph-seq mapped to dph-seq-0.4.0-be069f0bb710922a6ddd4ed2b91e3a6c\r\nwired-in package dph-par mapped to dph-par-0.4.0-b31a0ce10b7c92126978fcc929077ad6\r\nHsc static flags: -static\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\nPrelude> :module +Network.HTTP\r\nPrelude Network.HTTP> simpleHTTP (getRequest \"http://maps.google.com/maps/api/geocode/json?address=London&sensor=false\")\r\n*** Parser:\r\n*** Desugar:\r\n*** Simplify:\r\n*** CorePrep:\r\n*** ByteCodeGen:\r\nLoading package syb-0.1.0.2 ... linking ... done.\r\nLoading package base-3.0.3.2 ... linking ... done.\r\nLoading package parsec-2.1.0.1 ... linking ... done.\r\nLoading package network-2.2.1.7 ... linking ... done.\r\nLoading package mtl-1.1.0.2 ... linking ... done.\r\nLoading package bytestring-0.9.1.7 ... linking ... done.\r\nLoading package Win32-2.2.0.2 ... linking ... done.\r\nLoading package array-0.3.0.1 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.5 ... linking ... done.\r\nLoading package HTTP-4000.0.9 ... linking ... done.\r\n*GHC hangs here*\r\n}}}\r\n\r\nI'm using Windows XP SP3, Haskell Platform 2010.2.0.0. No firewall or proxy restrictions.\r\n\r\nThe bug was also reported here:\r\n[http://groups.google.com/group/haskell-cafe/browse_thread/thread/4e4a7e5eb92d1b81/48300428c7c10a57?lnk=gst&q=HTTP+package#48300428c7c10a57]\r\n\r\nThere's a file in attachment with Wireshark's capture during the sample execution.\r\n\r\nNote the same sample on ghc 6.12.1, haskell-network 2.2.1.7-3 on ArchLinux works just fine.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/4274Runtime should not set SIGPIPE to ignored for subprocesses2019-07-07T18:59:45Zphunge0Runtime should not set SIGPIPE to ignored for subprocessesThe GHC runtime ignores SIGPIPE by setting the signal
to SIG_IGN. This means that any subprocesses (created via
System.Process or otherwise) inwill also have their
SIGPIPE handler set to SIG_IGN; I think this might be
a bug. The Python r...The GHC runtime ignores SIGPIPE by setting the signal
to SIG_IGN. This means that any subprocesses (created via
System.Process or otherwise) inwill also have their
SIGPIPE handler set to SIG_IGN; I think this might be
a bug. The Python runtime does the same thing,
there's a good explanation of the drawbacks in:
http://bugs.python.org/issue1652
IMHO the simplest fix is the patch below: simply
avoid SIG_IGN, instead install a handler which does nothing.
This way, an exec() restores the handler to SIG_DFL. I've
included a testcase too.
Discussion link: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-August/019091.html. Summarizing: Donn Cave expressed concern that installing a signal handler for SIGPIPE might not be transparent to the rest of the program, but since the runtime already uses signal handlers for SIGVTALRM, it shouldn't make matters any worse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| 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":"Runtime should not set SIGPIPE to ignored for subprocesses","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC runtime ignores SIGPIPE by setting the signal\r\nto SIG_IGN. This means that any subprocesses (created via\r\nSystem.Process or otherwise) inwill also have their\r\nSIGPIPE handler set to SIG_IGN; I think this might be\r\na bug. The Python runtime does the same thing,\r\nthere's a good explanation of the drawbacks in:\r\nhttp://bugs.python.org/issue1652\r\n\r\nIMHO the simplest fix is the patch below: simply\r\navoid SIG_IGN, instead install a handler which does nothing.\r\nThis way, an exec() restores the handler to SIG_DFL. I've\r\nincluded a testcase too.\r\n\r\nDiscussion link: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-August/019091.html. Summarizing: Donn Cave expressed concern that installing a signal handler for SIGPIPE might not be transparent to the rest of the program, but since the runtime already uses signal handlers for SIGVTALRM, it shouldn't make matters any worse.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4362error in multithreaded program "epollControl: does not exist (No such file or...2019-07-07T18:59:20Zguesterror in multithreaded program "epollControl: does not exist (No such file or directory)"I wrote a program that is a standard multi threaded tcp server. It listens on a socket, and then it enters a loop where it does an accept for a new connection and then handles the connection on a new thread using forkIO. For each incomin...I wrote a program that is a standard multi threaded tcp server. It listens on a socket, and then it enters a loop where it does an accept for a new connection and then handles the connection on a new thread using forkIO. For each incoming connection, the program reads some data from the socket and then downloads a file from the web using the function simpleHTTP from the HTTP library.
My program runs fine most of the time, but every now and then when I run my program, all of the simpleHTTP calls throw an IOException, with the error:
```
epollControl: does not exist (No such file or directory)
```
My program also has an additional background thread, started at program startup with forkIO, that periodically calls simpleHTTP and these calls always work, and they continue to work even as the calls from the connection threads throw the above error.
From looking at the library code, it seems simpleHTTP eventually calls one of the low level socket functions which in turn calls System.Event.Thread.ensureIOManagerIsRunning, which calls System.Event.EPoll.new, which calls epoll_ctl which fails.
epoll_ctl man page tells me that the reason for this error is:
"ENOENT: op was EPOLL_CTL_MOD or EPOLL_CTL_DEL, and fd is not in epfd."
As I said above, this problem is hard to reproduce, it only happens once every 30 or so invocations of my program.
I am using ghc 7.1.20100925 and Linux 2.6.31
I am compiling with -threaded -O2
I'd be happy to give any any other needed information.
Thanks
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.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":"error in multithreaded program \"epollControl: does not exist (No such file or directory)\"","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wrote a program that is a standard multi threaded tcp server. It listens on a socket, and then it enters a loop where it does an accept for a new connection and then handles the connection on a new thread using forkIO. For each incoming connection, the program reads some data from the socket and then downloads a file from the web using the function simpleHTTP from the HTTP library.\r\n\r\nMy program runs fine most of the time, but every now and then when I run my program, all of the simpleHTTP calls throw an IOException, with the error:\r\n\r\n{{{\r\nepollControl: does not exist (No such file or directory)\r\n}}}\r\n\r\nMy program also has an additional background thread, started at program startup with forkIO, that periodically calls simpleHTTP and these calls always work, and they continue to work even as the calls from the connection threads throw the above error.\r\n\r\nFrom looking at the library code, it seems simpleHTTP eventually calls one of the low level socket functions which in turn calls System.Event.Thread.ensureIOManagerIsRunning, which calls System.Event.EPoll.new, which calls epoll_ctl which fails.\r\n\r\nepoll_ctl man page tells me that the reason for this error is:\r\n\"ENOENT: op was EPOLL_CTL_MOD or EPOLL_CTL_DEL, and fd is not in epfd.\"\r\n\r\nAs I said above, this problem is hard to reproduce, it only happens once every 30 or so invocations of my program.\r\n\r\nI am using ghc 7.1.20100925 and Linux 2.6.31\r\nI am compiling with -threaded -O2\r\n\r\nI'd be happy to give any any other needed information.\r\n\r\nThanks\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/4363openFile sharing permissions are inconsistent across platforms2019-07-07T18:59:20ZjysticopenFile sharing permissions are inconsistent across platformsSystem.IO.openFile seems to have inconsistent behaviour across platforms regarding file sharing permissions.
Given this program:
```
{-# LANGUAGE CPP #-}
import System.IO
import System.Process
main = do
h <- openFile "file.txt" W...System.IO.openFile seems to have inconsistent behaviour across platforms regarding file sharing permissions.
Given this program:
```
{-# LANGUAGE CPP #-}
import System.IO
import System.Process
main = do
h <- openFile "file.txt" WriteMode
hPutStrLn h "Success! I can see the file's contents."
hFlush h
#ifdef mingw32_HOST_OS
system "type file.txt"
#else
system "cat file.txt"
#endif
hClose h
```
Running under Ubuntu 10.04 / GHC 6.12.1, I get:
```
$ runghc openFile.hs
Success! I can see the file's contents.
```
Running under Windows 7 / GHC 6.12.3, I get:
```
> runghc openFile.hs
The process cannot access the file because it is being used by another process.
```
In my opinion the behaviour exhibited by Linux is preferable because it allows for log files to be written by long running processes. These log files can then be inspected externally while the Haskell process is still running.
The Snap Framework (snapframework.com) does this and it works great on Linux / Mac OS, but on Windows the log files cannot be viewed until after the server is shut down.
<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":"openFile sharing permissions are inconsistent across platforms","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"System.IO.openFile seems to have inconsistent behaviour across platforms regarding file sharing permissions.\r\n\r\nGiven this program:\r\n{{{\r\n{-# LANGUAGE CPP #-}\r\n\r\nimport System.IO\r\nimport System.Process\r\n\r\nmain = do\r\n h <- openFile \"file.txt\" WriteMode\r\n hPutStrLn h \"Success! I can see the file's contents.\"\r\n hFlush h\r\n#ifdef mingw32_HOST_OS\r\n system \"type file.txt\"\r\n#else\r\n system \"cat file.txt\"\r\n#endif\r\n hClose h\r\n}}}\r\n\r\nRunning under Ubuntu 10.04 / GHC 6.12.1, I get:\r\n{{{\r\n$ runghc openFile.hs\r\nSuccess! I can see the file's contents.\r\n}}}\r\n\r\nRunning under Windows 7 / GHC 6.12.3, I get:\r\n{{{\r\n> runghc openFile.hs\r\nThe process cannot access the file because it is being used by another process.\r\n}}}\r\n\r\nIn my opinion the behaviour exhibited by Linux is preferable because it allows for log files to be written by long running processes. These log files can then be inspected externally while the Haskell process is still running.\r\n\r\nThe Snap Framework (snapframework.com) does this and it works great on Linux / Mac OS, but on Windows the log files cannot be viewed until after the server is shut down.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1