GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:58:38Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4514IO manager can deadlock if a file descriptor is closed behind its back2019-07-07T18:58:38ZadeptIO manager can deadlock if a file descriptor is closed behind its backConsider the following simple "echo server":
```
module Main where
import Control.Concurrent
import Network
import System.IO
import System.Timeout
main :: IO ()
main = do
s <- listenOn (Service "7000")
loop s
return ()
...Consider the following simple "echo server":
```
module Main where
import Control.Concurrent
import Network
import System.IO
import System.Timeout
main :: IO ()
main = do
s <- listenOn (Service "7000")
loop s
return ()
loop :: Socket -> IO ThreadId
loop s = do
(hdr,_,_) <- accept s
hSetBuffering hdr LineBuffering
forkIO $ echo hdr
loop s
echo :: Handle -> IO ()
echo hdr = do
mstr <- timeout 5000000 $ hGetLine hdr
case mstr of
Just str -> do
hPutStrLn hdr str
hFlush hdr
echo hdr
Nothing -> do
putStrLn "Time out"
hClose hdr
return ()
```
When compiled without -threaded (GHC 7.0.1) it behaves as expected: you could "telnet localhost 7000", send a couple of lines, see them echoed back and if you don't type anything for 5 seconds, connection will be closed. If you connect for the second (third, ...) time, behavior will be the same.
Now, recompile the code with -threaded. On the first connect, everything would be as expected. However, after the first time out, when you "telnet" for the second time, behavior will be different.
1)Your lines would not be echoed back to you
2)Your connection would time out 5 seconds after you connected, no matter if you type and send something or not
See [this video (OGV, 1.5mb)](http://dl.dropbox.com/u/5748457/io-manager-cancel-fail.ogv) for demonstration of behavior with -threaded.
GHC 6.12.3 behaves correctly with -threaded and without, so I guess that new IO manager contributes to this situation.
This bug is confirmed to be present on Linux and MacOS X.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Timeout cannot properly cancel IO actions with new IO manager","status":"New","operating_system":"Unknown/Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following simple \"echo server\":\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Control.Concurrent\r\nimport Network\r\nimport System.IO\r\nimport System.Timeout\r\n\r\nmain :: IO ()\r\nmain = do\r\n s <- listenOn (Service \"7000\")\r\n loop s\r\n return ()\r\n \r\nloop :: Socket -> IO ThreadId\r\nloop s = do\r\n (hdr,_,_) <- accept s\r\n hSetBuffering hdr LineBuffering\r\n forkIO $ echo hdr\r\n loop s\r\n \r\necho :: Handle -> IO ()\r\necho hdr = do\r\n mstr <- timeout 5000000 $ hGetLine hdr\r\n case mstr of\r\n Just str -> do\r\n hPutStrLn hdr str\r\n hFlush hdr\r\n echo hdr\r\n Nothing -> do\r\n putStrLn \"Time out\"\r\n hClose hdr\r\n return ()\r\n}}}\r\n\r\nWhen compiled without -threaded (GHC 7.0.1) it behaves as expected: you could \"telnet localhost 7000\", send a couple of lines, see them echoed back and if you don't type anything for 5 seconds, connection will be closed. If you connect for the second (third, ...) time, behavior will be the same.\r\n\r\nNow, recompile the code with -threaded. On the first connect, everything would be as expected. However, after the first time out, when you \"telnet\" for the second time, behavior will be different. \r\n\r\n1)Your lines would not be echoed back to you\r\n2)Your connection would time out 5 seconds after you connected, no matter if you type and send something or not\r\n\r\nSee [http://dl.dropbox.com/u/5748457/io-manager-cancel-fail.ogv this video (OGV, 1.5mb)] for demonstration of behavior with -threaded.\r\n\r\nGHC 6.12.3 behaves correctly with -threaded and without, so I guess that new IO manager contributes to this situation.\r\n\r\nThis bug is confirmed to be present on Linux and MacOS X.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2bosboshttps://gitlab.haskell.org/ghc/ghc/-/issues/4512EventLog does not play well with forkProcess2019-07-07T18:58:39ZadeptEventLog does not play well with forkProcessI am trying to see an eventlog of process that daemonizes itself via forkProcess.
Unfortunately, as parent process dies, he writes out his eventlog (or at least a header part, I haven't checked exactly), and eventlog of the child proces...I am trying to see an eventlog of process that daemonizes itself via forkProcess.
Unfortunately, as parent process dies, he writes out his eventlog (or at least a header part, I haven't checked exactly), and eventlog of the child process is then appended to the same file.
As a result, neither ghc-events nor threadscope is able to read the eventlog file.
I've modified the program so that it would not fork, and generated "good" eventlog. I'm attaching it and "bad" eventlog as well so you can see the difference by yourself.
Perhaps "+RTS -ls" could write output to filename that includes the PID of the process, like "program.$PID.eventlog"?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"EventLog does not play well with forkProcess","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to see an eventlog of process that daemonizes itself via forkProcess. \r\n\r\nUnfortunately, as parent process dies, he writes out his eventlog (or at least a header part, I haven't checked exactly), and eventlog of the child process is then appended to the same file.\r\n\r\nAs a result, neither ghc-events nor threadscope is able to read the eventlog file.\r\n\r\nI've modified the program so that it would not fork, and generated \"good\" eventlog. I'm attaching it and \"bad\" eventlog as well so you can see the difference by yourself.\r\n\r\nPerhaps \"+RTS -ls\" could write output to filename that includes the PID of the process, like \"program.$PID.eventlog\"?","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4504"awaitSignal Nothing" does not block thread with -threaded2019-07-07T18:58:41Zadept"awaitSignal Nothing" does not block thread with -threadedConsider the following code:
```
module Main where
import System.Posix.Signals
import Control.Concurrent
main :: IO ()
main = do
awaitSignal Nothing >> yield
```
According to the System.Posix.Signals haddock, "awaitSignal Nothing" ...Consider the following code:
```
module Main where
import System.Posix.Signals
import Control.Concurrent
main :: IO ()
main = do
awaitSignal Nothing >> yield
```
According to the System.Posix.Signals haddock, "awaitSignal Nothing" should call pause(2), causing main thread to block until some signal has arrived. This is indeed what happens when this code is compiled by GHC 7.0.1 like so: "ghc --make awaitSignal.hs".
However, when compiled with -threaded, this code exits immediately when run. I think this is a bug in -threaded runtime.
I've tested with GHC 6.12.1, and this behavior is present there as well. Maybe I'm missing something non-obvious here?
My environment: x86, Debian sid, GHC 6.12.1 from Debian packages, GHC 7.0.1 from binary packages from GHC site.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"\"awaitSignal Nothing\" does not block thread with -threaded","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Posix.Signals\r\nimport Control.Concurrent\r\n\r\nmain :: IO ()\r\nmain = do\r\n awaitSignal Nothing >> yield\r\n}}}\r\n\r\nAccording to the System.Posix.Signals haddock, \"awaitSignal Nothing\" should call pause(2), causing main thread to block until some signal has arrived. This is indeed what happens when this code is compiled by GHC 7.0.1 like so: \"ghc --make awaitSignal.hs\".\r\n\r\nHowever, when compiled with -threaded, this code exits immediately when run. I think this is a bug in -threaded runtime.\r\n\r\nI've tested with GHC 6.12.1, and this behavior is present there as well. Maybe I'm missing something non-obvious here?\r\n\r\nMy environment: x86, Debian sid, GHC 6.12.1 from Debian packages, GHC 7.0.1 from binary packages from GHC site.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/4493Child from forkProcess calls select/read on parent's Handle, stealing data fr...2019-07-07T18:58:44ZjoshChild from forkProcess calls select/read on parent's Handle, stealing data from parentIn trying out [git-annex](http://git-annex.branchable.com/) on a large repository, I ran into a strange bug where git-annex would try to operate on a filename that consisted of the beginning of one filename spliced together with the end ...In trying out [git-annex](http://git-annex.branchable.com/) on a large repository, I ran into a strange bug where git-annex would try to operate on a filename that consisted of the beginning of one filename spliced together with the end of another filename. After staring at strace output for a while, I tracked down the problem, though not the root cause. git-annex would call pipeFrom (from MissingH's System.Cmd.Utils), which (by way of hPipeFrom) would call forkProcess to get a child process, and then call dupTo, close the original fd, and call execProcess to run the specified process. The parent process, in turn, would call fdToHandle on the other end of the pipe, and then pipeFrom would call hGetContents on that handle. In the version of git-annex I originally tested (the 0.04 release), more than one of these pipes might run at once. strace showed that on occasion, the child process created by forkProcess would call select on the file descriptor for a \*previous\* pipe, and read from that previous pipe, stealing data from the parent process; it would do this at some point after starting and before calling exec.
I reproduced this problem with 6.12.1 and 6.10.4, both with and without -threaded. The analysis of the strace given above came from 6.12.1 without -threaded. (Note that with -threaded, strace would fail at runtime, with "PANIC: attached pid $SOMEPID exited with 0"; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603187 . So, I don't have an strace to analyze from -threaded.)
I can reliably reproduce this problem. Please let me know if I can provide any further information.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | joey@kitenet.net, josh@joshtriplett.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Child from forkProcess calls select/read on parent's Handle, stealing data from parent","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["joey@kitenet.net","josh@joshtriplett.org"],"type":"Bug","description":"In trying out [http://git-annex.branchable.com/ git-annex] on a large repository, I ran into a strange bug where git-annex would try to operate on a filename that consisted of the beginning of one filename spliced together with the end of another filename. After staring at strace output for a while, I tracked down the problem, though not the root cause. git-annex would call pipeFrom (from MissingH's System.Cmd.Utils), which (by way of hPipeFrom) would call forkProcess to get a child process, and then call dupTo, close the original fd, and call execProcess to run the specified process. The parent process, in turn, would call fdToHandle on the other end of the pipe, and then pipeFrom would call hGetContents on that handle. In the version of git-annex I originally tested (the 0.04 release), more than one of these pipes might run at once. strace showed that on occasion, the child process created by forkProcess would call select on the file descriptor for a *previous* pipe, and read from that previous pipe, stealing data from the parent process; it would do this at some point after starting and before calling exec.\r\n\r\nI reproduced this problem with 6.12.1 and 6.10.4, both with and without -threaded. The analysis of the strace given above came from 6.12.1 without -threaded. (Note that with -threaded, strace would fail at runtime, with \"PANIC: attached pid $SOMEPID exited with 0\"; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603187 . So, I don't have an strace to analyze from -threaded.)\r\n\r\nI can reliably reproduce this problem. Please let me know if I can provide any further information.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4480System.Directory.canonicalizePath gives bad result2019-07-07T18:58:48ZerikdSystem.Directory.canonicalizePath gives bad resultRunning ghci on linux with an empty path gives different wrong results each time:
```
Prelude> System.Directory.canonicalizePath []
"\153\229\228]\170\DEL"
Prelude> System.Directory.canonicalizePath []
"\160\147\155\\\170\DE...Running ghci on linux with an empty path gives different wrong results each time:
```
Prelude> System.Directory.canonicalizePath []
"\153\229\228]\170\DEL"
Prelude> System.Directory.canonicalizePath []
"\160\147\155\\\170\DEL"
Prelude> System.Directory.canonicalizePath []
"\136"
```
As pointed out by geheimdienst on \#haskell:
my speculation is this: canonicalizePath calls realpath, which
for "" gives an EINVAL with the result string being undefined.
> haskell forgets to check errno and takes the undefined string
This bug exists on 6.12.1 on Debian and 6.12.3 on FreeBSD.7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4465GHCi linker failure on Windows2019-07-07T18:58:52ZjoellathropGHCi linker failure on WindowsOn Windows, GHCi seems unable to find a DLL in a non-standard location, even when that location is provided with -L.
Presume a valid DLL named "foo.dll" in "c:\\temp\\test". An attempt to load "foo" into GHCi when the current working di...On Windows, GHCi seems unable to find a DLL in a non-standard location, even when that location is provided with -L.
Presume a valid DLL named "foo.dll" in "c:\\temp\\test". An attempt to load "foo" into GHCi when the current working directory is "c:\\temp\\test" is successful:
```
C:\temp\test>ghci -lfoo
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) foo ... done
final link ... done
Prelude>
```
However, if the current working directory is "c:\\temp" all attempts to load "foo" into GHCi using the -L switch fail:
```
C:\temp>ghci -lfoo -Ltest
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
: foo: The specified module could not be found.
Loading object (dynamic) foo ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no
t load DLL)
Whilst trying to load: (dynamic) foo
Additional directories searched: test
```
```
C:\temp>ghci -lfoo -L\temp\test
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
: foo: The specified module could not be found.
Loading object (dynamic) foo ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no
t load DLL)
Whilst trying to load: (dynamic) foo
Additional directories searched: \temp\test
```
```
C:\temp>ghci -lfoo -Lc:\temp\test
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
: foo: The specified module could not be found.
Loading object (dynamic) foo ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no
t load DLL)
Whilst trying to load: (dynamic) foo
Additional directories searched: c:\temp\test
```
However, GHCi has no problem loading "foo" if the path component is included in the -l option. (Naturally, this is not ideal and far from the accepted usage of -l and -L.)
```
C:\temp>ghci -ltest\foo
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) test\foo ... done
final link ... done
Prelude>
```
Finally, this issue does not manifest on Linux. Everything seems to work fine there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | joell@sunbeltsoftware.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi linker failure on Windows","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["-L","DLL","ghci","linker"],"differentials":[],"test_case":"","architecture":"","cc":["joell@sunbeltsoftware.com"],"type":"Bug","description":"On Windows, GHCi seems unable to find a DLL in a non-standard location, even when that location is provided with -L.\r\n\r\nPresume a valid DLL named \"foo.dll\" in \"c:\\temp\\test\". An attempt to load \"foo\" into GHCi when the current working directory is \"c:\\temp\\test\" is successful:\r\n\r\n{{{\r\nC:\\temp\\test>ghci -lfoo\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nLoading object (dynamic) foo ... done\r\nfinal link ... done\r\nPrelude>\r\n}}}\r\n\r\nHowever, if the current working directory is \"c:\\temp\" all attempts to load \"foo\" into GHCi using the -L switch fail:\r\n\r\n{{{\r\nC:\\temp>ghci -lfoo -Ltest\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n: foo: The specified module could not be found.\r\nLoading object (dynamic) foo ... failed.\r\n<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no\r\nt load DLL)\r\nWhilst trying to load: (dynamic) foo\r\nAdditional directories searched: test\r\n}}}\r\n\r\n{{{\r\nC:\\temp>ghci -lfoo -L\\temp\\test\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n: foo: The specified module could not be found.\r\nLoading object (dynamic) foo ... failed.\r\n<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no\r\nt load DLL)\r\nWhilst trying to load: (dynamic) foo\r\nAdditional directories searched: \\temp\\test\r\n}}}\r\n\r\n{{{\r\nC:\\temp>ghci -lfoo -Lc:\\temp\\test\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n: foo: The specified module could not be found.\r\nLoading object (dynamic) foo ... failed.\r\n<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: could no\r\nt load DLL)\r\nWhilst trying to load: (dynamic) foo\r\nAdditional directories searched: c:\\temp\\test\r\n}}}\r\n\r\nHowever, GHCi has no problem loading \"foo\" if the path component is included in the -l option. (Naturally, this is not ideal and far from the accepted usage of -l and -L.)\r\n\r\n{{{\r\nC:\\temp>ghci -ltest\\foo\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nLoading object (dynamic) test\\foo ... done\r\nfinal link ... done\r\nPrelude>\r\n}}}\r\n\r\nFinally, this issue does not manifest on Linux. Everything seems to work fine there.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4452Graphics.Win32.GDI.Clip.enumClipboardFormats fails on success.2019-07-07T18:58:56ZRyan YatesGraphics.Win32.GDI.Clip.enumClipboardFormats fails on success.According to the documentation for the Win32 !EnumClipboardFormats function:
http://msdn.microsoft.com/en-us/library/ms649038(VS.85).aspx
A return value of zero is only an error if a subsequent call to !GetLastError does not return ERR...According to the documentation for the Win32 !EnumClipboardFormats function:
http://msdn.microsoft.com/en-us/library/ms649038(VS.85).aspx
A return value of zero is only an error if a subsequent call to !GetLastError does not return ERROR_SUCCESS. The following code is what I would expect:
```
errorWinNotErrorSuccess :: (Num a) => String -> IO a
errorWinNotErrorSuccess fn_name = do
err_code <- getLastError
if err_code == 0 then return 0 else failWith fn_name err_code
failIfZeroAndNotErrorSuccess :: Num a => String -> IO a -> IO a
failIfZeroAndNotErrorSuccess wh act = do
v <- act
if v == 0 then errorWinNotErrorSuccess wh else return v
enumClipboardFormats :: ClipboardFormat -> IO ClipboardFormat
enumClipboardFormats format =
failIfZeroAndNotErrorSuccess "EnumClipboardFormats" $ c_EnumClipboardFormats format
```
Instead of the current:
```
enumClipboardFormats :: ClipboardFormat -> IO ClipboardFormat
enumClipboardFormats format =
failIfZero "EnumClipboardFormats" $ c_EnumClipboardFormats format
```7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/4441NCG miscompiles Double -> Float -> Double2019-07-07T18:58:59ZdtereiNCG miscompiles Double -> Float -> DoubleI have a need to truncate a double to only float precision but then store it back in a double as I'm printing from the double to a hexadecimal representation.
To achieve this I basically do two calls to realToFrac. A test case for this ...I have a need to truncate a double to only float precision but then store it back in a double as I'm printing from the double to a hexadecimal representation.
To achieve this I basically do two calls to realToFrac. A test case for this is below. When I compile it with -fasm -O it appears as if '(realToFrac . realToFrac)' is changed to 'id'. (Not what actually happens as bug occurs in NCG, after Core stage, but thats how the programs behaviour is changed). This bug is specific to -fasm, compiling the program below with -fllvm or -fvia-C produces the correct results.
Test Case:
```
module Main where
import Numeric
import System.IO
-- Test runner
main = do
putStr "Enter a double: "
hFlush stdout
d <- double
print $ "Float Version : " ++ (fToStr $ realToFrac d)
print $ "Double Version: " ++ (dToStr d)
double :: IO Double
double = do
x <- getLine
return $ read x
dToStr :: Double -> String
dToStr d = show d
fToStr :: Float -> String
fToStr = (dToStr . realToFrac)
```
Output with '-fasm -O':
```
$ ./TestCase
Enter a double: 2.0e-2
Float Version : 2.0e-2
Double Version: 2.0e-2
```
Output with '-fvia-C -O':
```
$ ./TestCase
Enter a double: 2.0e-2
Float Version : 1.9999999552965164e-2
Double Version: 2.0e-2
```7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4427hGetBuf sometimes reads fewer bytes than required2019-07-07T18:59:03Zrl@cse.unsw.edu.auhGetBuf sometimes reads fewer bytes than requiredThe attached program repeatedly calls `hGetBuf` and prints how much it wanted to read and how many bytes `hGetBuf` returned. It should be run on a sufficiently large file. On Cygwin, the last 4 lines of the output are:
```
4 4
608 523
4...The attached program repeatedly calls `hGetBuf` and prints how much it wanted to read and how many bytes `hGetBuf` returned. It should be run on a sufficiently large file. On Cygwin, the last 4 lines of the output are:
```
4 4
608 523
4 4
300 300
```
Note that we requested 608 bytes but `hGetBuf` only returned 523 even though we weren't at the end of file (since subsequent reads succeeded).
I suspect the bug is in `GHC.IO.Handle.Text.bufReadEmpty`, namely here:
```
loop :: FD -> Int -> Int -> IO Int
loop fd off bytes | bytes <= 0 = return off
```
It should probably return `so_far + off`.
<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":"hGetBuf sometimes reads fewer bytes than required","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":"The attached program repeatedly calls `hGetBuf` and prints how much it wanted to read and how many bytes `hGetBuf` returned. It should be run on a sufficiently large file. On Cygwin, the last 4 lines of the output are:\r\n\r\n{{{\r\n4 4\r\n608 523\r\n4 4\r\n300 300\r\n}}}\r\n\r\nNote that we requested 608 bytes but `hGetBuf` only returned 523 even though we weren't at the end of file (since subsequent reads succeeded).\r\n\r\nI suspect the bug is in `GHC.IO.Handle.Text.bufReadEmpty`, namely here:\r\n\r\n{{{\r\n loop :: FD -> Int -> Int -> IO Int\r\n loop fd off bytes | bytes <= 0 = return off\r\n}}}\r\n\r\nIt should probably return `so_far + off`.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4389Unexpcted failure, ambiguous type variable defaulted (ghci)2019-07-07T18:59:13Zdaniel.is.fischerUnexpcted failure, ambiguous type variable defaulted (ghci)```
=====> print019(ghci) 1444 of 2601 [0, 0, 0]
cd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/h...```
=====> print019(ghci) 1444 of 2601 [0, 0, 0]
cd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz -ignore-dot-ghci <print019.script >print019.run.stdout 2>print019.run.stderr
Actual stderr output differs from expected:
--- ./ghci.debugger/scripts/print019.stderr.normalised 2010-10-12 20:42:15.000000000 +0200
+++ ./ghci.debugger/scripts/print019.run.stderr.normalised 2010-10-12 20:42:15.000000000 +0200
@@ -1,7 +0,0 @@
-
-<interactive>:1:1:
- Ambiguous type variable `t1' in the constraint:
- (Show t1) arising from a use of `print'
- Cannot resolve unknown runtime types: t1
- Use :print or :force to determine these types
- In a stmt of an interactive GHCi command: print it
*** unexpected failure for print019(ghci)
```
Unexpectedly, the type variable was resolved.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpcted failure, ambiguous type variable defaulted (ghci)","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> print019(ghci) 1444 of 2601 [0, 0, 0]\r\ncd ./ghci.debugger/scripts && HC='/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz ' '/home/dafis/Haskell/Hacking/newghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -optl-lz -ignore-dot-ghci <print019.script >print019.run.stdout 2>print019.run.stderr\r\nActual stderr output differs from expected:\r\n--- ./ghci.debugger/scripts/print019.stderr.normalised 2010-10-12 20:42:15.000000000 +0200\r\n+++ ./ghci.debugger/scripts/print019.run.stderr.normalised 2010-10-12 20:42:15.000000000 +0200\r\n@@ -1,7 +0,0 @@\r\n-\r\n-<interactive>:1:1:\r\n- Ambiguous type variable `t1' in the constraint:\r\n- (Show t1) arising from a use of `print'\r\n- Cannot resolve unknown runtime types: t1\r\n- Use :print or :force to determine these types\r\n- In a stmt of an interactive GHCi command: print it\r\n*** unexpected failure for print019(ghci)\r\n}}}\r\nUnexpectedly, the type variable was resolved.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4383Uncanonical display of Double2019-07-07T18:59:15Zdaniel.is.fischerUncanonical display of Double```
Prelude> 0.5 ^ 1030
0.8691694759794e-310
```
Should of course be 8.69...e-311, just to have it on record for now.
I'll take a look at the showing code one of the next days.
<details><summary>Trac metadata</summary>
| Trac field ...```
Prelude> 0.5 ^ 1030
0.8691694759794e-310
```
Should of course be 8.69...e-311, just to have it on record for now.
I'll take a look at the showing code one of the next days.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Uncanonical display of Double","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["Double,","show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nPrelude> 0.5 ^ 1030\r\n0.8691694759794e-310\r\n}}}\r\nShould of course be 8.69...e-311, just to have it on record for now.\r\n\r\nI'll take a look at the showing code one of the next days.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/4381scaleFloat does not handle overflow correctly.2019-07-07T18:59:15ZdraconxscaleFloat does not handle overflow correctly.If you call scaleFloat with a somewhat large integer value, the result
correctly overflows and yields Infinity. However, if you call scaleFloat
with an extremely large integer value, the result is finite!
```
> scaleFloat 30000 1
Infini...If you call scaleFloat with a somewhat large integer value, the result
correctly overflows and yields Infinity. However, if you call scaleFloat
with an extremely large integer value, the result is finite!
```
> scaleFloat 30000 1
Infinity
> scaleFloat (maxBound :: Int) 1
0.5
```
<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":"scaleFloat does not handle overflow correctly.","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":"If you call scaleFloat with a somewhat large integer value, the result\r\ncorrectly overflows and yields Infinity. However, if you call scaleFloat\r\nwith an extremely large integer value, the result is finite!\r\n\r\n{{{\r\n> scaleFloat 30000 1\r\nInfinity\r\n\r\n> scaleFloat (maxBound :: Int) 1\r\n0.5\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://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.1https://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/4335fromRational broken for Ratio a2021-11-02T09:27:32Zdaniel.is.fischerfromRational broken for Ratio aThe `Fractional` instance for `Ratio a` in GHC.Real defines
```
fromRational (x:%y) = fromInteger x :% fromInteger y
```
For fixed-width Integral types, that produces invalid results:
```
Prelude Data.Ratio> fromRational (1 % 2^3...The `Fractional` instance for `Ratio a` in GHC.Real defines
```
fromRational (x:%y) = fromInteger x :% fromInteger y
```
For fixed-width Integral types, that produces invalid results:
```
Prelude Data.Ratio> fromRational (1 % 2^32) :: Ratio Int
1 % 0
Prelude Data.Ratio> fromRational (3 % (2^32+9)) :: Ratio Int
3 % 9
```
Via `toRational`, these can be ported back to `Rational`.
`Ratio a` is generally broken for fixed-width types:
```
Prelude Data.Ratio> 1 % (minBound :: Int)
(-1) % (-2147483648)
```
but the particular brokenness of `fromRational` can be alleviated by reducing:
```
fromRational (x:%y) = fromInteger x % fromInteger y
{-# RULES
"fromRational/id" fromRational = id :: Rational -> Rational
#-}
```
I think it's better to throw a divide by zero error than to produce invalid results here.
<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":"fromRational broken for Ratio a","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":"The `Fractional` instance for `Ratio a` in GHC.Real defines\r\n{{{\r\n fromRational (x:%y) = fromInteger x :% fromInteger y\r\n}}}\r\nFor fixed-width Integral types, that produces invalid results:\r\n{{{\r\nPrelude Data.Ratio> fromRational (1 % 2^32) :: Ratio Int\r\n1 % 0\r\nPrelude Data.Ratio> fromRational (3 % (2^32+9)) :: Ratio Int\r\n3 % 9\r\n}}}\r\nVia `toRational`, these can be ported back to `Rational`.\r\n\r\n`Ratio a` is generally broken for fixed-width types:\r\n{{{\r\nPrelude Data.Ratio> 1 % (minBound :: Int)\r\n(-1) % (-2147483648)\r\n}}}\r\nbut the particular brokenness of `fromRational` can be alleviated by reducing:\r\n{{{\r\n fromRational (x:%y) = fromInteger x % fromInteger y\r\n\r\n{-# RULES\r\n\"fromRational/id\" fromRational = id :: Rational -> Rational\r\n #-}\r\n}}}\r\nI think it's better to throw a divide by zero error than to produce invalid results here.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://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/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/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/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/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 Marlow