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/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/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/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/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/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/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/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/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/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/3961-O results in incorrect behavior2019-07-07T19:01:20Zrichardg@richardg.name-O results in incorrect behaviorHUnit 1.2.2.1 ships with a set of unit tests. Incorrect behavior occurs when these tests are compiled into a program using Cabal and GHC 6.12.1 (Haskell Platform 2010.1).
Correct behavior occurs when these tests are:
- compiled using `...HUnit 1.2.2.1 ships with a set of unit tests. Incorrect behavior occurs when these tests are compiled into a program using Cabal and GHC 6.12.1 (Haskell Platform 2010.1).
Correct behavior occurs when these tests are:
- compiled using `ghc --make` using GHC 6.12.1.
- run using GHCi 6.12.1.
- compiled into a program using Cabal and GHC 6.10.4 (Haskell Platform 2009.2).
- compiled using `ghc --make` using GHC 6.10.4.
- run using GHCi 6.10.4.
This behavior appears to involve interactions between the Testable and Assertable classes and instances in `Test/HUnit/Base.hs`. This affects the correctness of the programs.
<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":"HUnit has erroneous behavior when compiled with Cabal","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":"HUnit 1.2.2.1 ships with a set of unit tests. Incorrect behavior occurs when these tests are compiled into a program using Cabal and GHC 6.12.1 (Haskell Platform 2010.1).\r\n\r\nCorrect behavior occurs when these tests are:\r\n * compiled using {{{ghc --make}}} using GHC 6.12.1.\r\n * run using GHCi 6.12.1.\r\n * compiled into a program using Cabal and GHC 6.10.4 (Haskell Platform 2009.2). \r\n * compiled using {{{ghc --make}}} using GHC 6.10.4.\r\n * run using GHCi 6.10.4.\r\n\r\nThis behavior appears to involve interactions between the Testable and Assertable classes and instances in {{{Test/HUnit/Base.hs}}}. This affects the correctness of the programs.","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/3911HughesPJ.vcat should behave like 'foldr ($$) empty', not like 'foldr ($+$) em...2019-07-07T19:01:35ZbenediktHughesPJ.vcat should behave like 'foldr ($$) empty', not like 'foldr ($+$) empty'The performance tuning for libraries/pretty applied in June 2008
```
Tue Jun 24 12:37:15 BST 2008 benedikt.huber@gmail.com
* fillNB bug, lazy vcat
```
accidentally changed the behavior of vcat to `foldr ($+$) empty`, although it sh...The performance tuning for libraries/pretty applied in June 2008
```
Tue Jun 24 12:37:15 BST 2008 benedikt.huber@gmail.com
* fillNB bug, lazy vcat
```
accidentally changed the behavior of vcat to `foldr ($+$) empty`, although it should be `foldr ($$) empty`, according to the documentation. Fixing this is simple (patch attached).
```
hunk ./Text/PrettyPrint/HughesPJ.hs 497
-vcat = reduceAB . foldr (above_' True) empty
+vcat = reduceAB . foldr (above_' False) empty
```
See:
http://www.haskell.org/pipermail/libraries/2008-December/011032.html
http://www.haskell.org/pipermail/libraries/2010-March/013067.html
It would be nice to add a test case, but I'm not sure where to put it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/pretty |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HughesPJ.vcat should behave like 'foldr ($$) empty', not like 'foldr ($+$) empty'","status":"New","operating_system":"","component":"libraries/pretty","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The performance tuning for libraries/pretty applied in June 2008\r\n{{{\r\nTue Jun 24 12:37:15 BST 2008 benedikt.huber@gmail.com\r\n * fillNB bug, lazy vcat \r\n}}}\r\naccidentally changed the behavior of vcat to {{{foldr ($+$) empty}}}, although it should be {{{foldr ($$) empty}}}, according to the documentation. Fixing this is simple (patch attached).\r\n{{{\r\nhunk ./Text/PrettyPrint/HughesPJ.hs 497\r\n-vcat = reduceAB . foldr (above_' True) empty\r\n+vcat = reduceAB . foldr (above_' False) empty\r\n}}}\r\n\r\nSee:\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2008-December/011032.html\r\nhttp://www.haskell.org/pipermail/libraries/2010-March/013067.html\r\n\r\nIt would be nice to add a test case, but I'm not sure where to put it.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3800sizeofByteArray# returns allocated words, not requested length in bytes2019-07-07T19:02:06ZAntoineLattersizeofByteArray# returns allocated words, not requested length in bytesA byte array allocated with (`GHC.Prim.newByteArray# 7`) will report it's size as '8' - that is, the stored size in `StgArrWords` is the number of allocated words, not the number of requested bytes.
This menas that if I want to a `GHC.P...A byte array allocated with (`GHC.Prim.newByteArray# 7`) will report it's size as '8' - that is, the stored size in `StgArrWords` is the number of allocated words, not the number of requested bytes.
This menas that if I want to a `GHC.Prim.ByteArray#` or `MutableByteArray#` as an array type, I need a separate length fields.
See also: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018199.htmlhttps://gitlab.haskell.org/ghc/ghc/-/issues/3745Non-deterministic behavior with FFI2019-07-07T19:02:29ZgchrupalaNon-deterministic behavior with FFII have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is a...I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine.
The same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC.
I attach a simplified extract of the code which will show the problem.
I included:
- c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation
- test.hs : Haskell program which calls the C++ function via FFI
- test.cpp : Equivalent C++ program which calls the same C++ function
- run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results
- train : data file which the programs process
I compiled using GHC 6.10.4 like this:
```
ghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++
```
To see the problem execute:
```
./run.sh ./test-ghc-6.10.4
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Non-deterministic behavior with FFI","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine.\r\n\r\nThe same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC.\r\n\r\nI attach a simplified extract of the code which will show the problem. \r\n\r\nI included: \r\n\r\n* c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation\r\n\r\n* test.hs : Haskell program which calls the C++ function via FFI\r\n\r\n* test.cpp : Equivalent C++ program which calls the same C++ function\r\n\r\n* run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results\r\n\r\n* train : data file which the programs process\r\n\r\n\r\nI compiled using GHC 6.10.4 like this:\r\n{{{\r\nghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++\r\n}}}\r\n\r\nTo see the problem execute:\r\n{{{\r\n./run.sh ./test-ghc-6.10.4\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2https://gitlab.haskell.org/ghc/ghc/-/issues/3516[PATCH] ppc64: broken 'foreign import wrapper'2019-07-07T19:03:32ZSergei Trofimovich[PATCH] ppc64: broken 'foreign import wrapper'Attaching simple testcase failing horribly on ppc64:
amd64 test output:
```
$ ./dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback functio...Attaching simple testcase failing horribly on ppc64:
amd64 test output:
```
$ ./dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:H(72)H(33)[result = 735]
TEST PASSED
```
ppc64 test output:
```
$ dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:[result = 105]
Segmentation fault
```
As you see **C call with registered Hs-C callback function** called not a registered function, but something strange. There is no even registered callback (glo_cb == 0).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ppc64: broken 'foreign import wrapper'","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["ffi,","wrapper"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attaching simple testcase failing horribly on ppc64:\r\n\r\namd64 test output:\r\n{{{\r\n$ ./dist/build/fct/fct\r\nC call:[result = 105]\r\n\r\nC call with registered C callback function:C(72)C(33)[result = 735]\r\n\r\nC call with registered Hs-C callback function:H(72)H(33)[result = 735]\r\n\r\nTEST PASSED\r\n}}}\r\n\r\nppc64 test output:\r\n{{{\r\n$ dist/build/fct/fct\r\nC call:[result = 105]\r\n\r\nC call with registered C callback function:C(72)C(33)[result = 735]\r\n\r\nC call with registered Hs-C callback function:[result = 105]\r\n\r\nSegmentation fault\r\n\r\n}}}\r\n\r\nAs you see '''C call with registered Hs-C callback function''' called not a registered function, but something strange. There is no even registered callback (glo_cb == 0).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2https://gitlab.haskell.org/ghc/ghc/-/issues/24505Instances getting incorrect IPE data2024-03-12T15:11:17ZFinley McIlwaineInstances getting incorrect IPE dataCode:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
import GHC.InfoProv
import Unsafe.Coerce
-- Boilerplate to help us access the literal dictionaries
data Dict c where
Dict :: forall c. c => Dict c
data Bo...Code:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
import GHC.InfoProv
import Unsafe.Coerce
-- Boilerplate to help us access the literal dictionaries
data Dict c where
Dict :: forall c. c => Dict c
data Box where
Box :: forall a. a -> Box
mkBox :: forall a. a => Box
mkBox = unsafeCoerce (Dict @a)
-- Interesting bit
data A = A
instance Eq A where
A == A = True
instance Ord A where
A <= A = undefined
main :: IO ()
main = do
(\(Box d) -> print =<< whereFrom d) $ mkBox @(Eq A)
(\(Box d) -> print =<< whereFrom d) $ mkBox @(Ord A)
```
This program prints the IPE data of the `Eq A` and `Ord A` dictionaries. The `Eq A` dictionary looks as we would expect, with `ipLabel = $fEqA`. The `Ord A` dictionary, however, gets the label `<`. Compile with:
```
ghc -O -fforce-recomp -finfo-table-map -fdistinct-constructor-tables Main.hs
```
The program outputs:
```
Just (InfoProv {ipName = "C:Eq_Main_0_con_info", ipDesc = CONSTR_2_0, ipTyDesc = "Eq", ipLabel = "$fEqA", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "23:10-13"})
Just (InfoProv {ipName = "C:Ord_Main_0_con_info", ipDesc = CONSTR, ipTyDesc = "Ord", ipLabel = "<", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "26:10-14"})
```
I would expect the `Ord` label to be `$fOrdA`, not `<`.
Interestingly, if we add more explicit definitions to the `Ord A` instance, the label changes. Changing the instance to:
```haskell
instance Ord A where
A <= A = undefined
compare = undefined
```
Changes the label to `>` instead of `<`:
```
Just (InfoProv {ipName = "C:Ord_Main_0_con_info", ipDesc = CONSTR, ipTyDesc = "Ord", ipLabel = ">", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "26:10-14"})
```