GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:00:55Zhttps://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/4049Support for ABI versioning of C libraries2019-07-07T19:00:57ZmpiechotkaSupport for ABI versioning of C librariesCurrently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts an...Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.
More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for ldscripts and ABI versioning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.\r\n\r\nAlso it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.\r\n\r\nMore informations:\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=290974\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=311361","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4041possible misbehaviour of hGet/hGetBuf2019-07-07T19:00:59Zduncanpossible misbehaviour of hGet/hGetBufnominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.
Simon Marlow recently added this documentation to `ByteS...nominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.
Simon Marlow recently added this documentation to `ByteString.hGet`:
```
-- If there is any data to read, then 'hGet' will not block, instead
-- it will return whatever data is available without blocking. It
-- only blocks if there is no data available to read.
```
nominolo reports that with ghc-6.12.1 on OSX SL, that the actual behaviour is that `hGet` blocks until all the requested data is available, that is, it does not return a short read.
Simon clearly thinks that the documented behaviour of hGet is what the behaviour ought to be. In a previous patch to the `ByteString` package he writes:
```
Mon Mar 22 15:39:14 GMT 2010 Simon Marlow <marlowsd@gmail.com>
* hGetContents: use hGet instead of hGetNonBlocking + hWaitForInput + hIsEOF
Not only is this cleaner, but it fixes a problem with read binary data
over a pipe, see
http://hackage.haskell.org/trac/ghc/ticket/3808
The problem is that bytestring normally works fine when the Handle is
not in binary mode, because it uses hGetBuf/hPutBuf which bypass the
encoding layer. That is, except in this one particular case:
hWaitForInput might do some decoding, because it has to determine
whether there are any characters (not bytes) available to be read.
I imagine hGetNonBlocking was used due to concerns that hGet might
block if there is insufficient data, but that's not the case; hGet
returns a short read if it would otherwise block, and only blocks if
there is no data to read.
```
So it's not entirely clear what is going on. It's either confusion or a bug (possibly a system-dependent one).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"possible misbehaviour of hGet/hGetBuf","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"nominolo reports that the `ByteString.hGet` does not have the behaviour it is documented to have. `ByteString.hGet` is implemented almost directly in terms of `System.IO.hGetBuf`.\r\n\r\nSimon Marlow recently added this documentation to `ByteString.hGet`:\r\n{{{\r\n-- If there is any data to read, then 'hGet' will not block, instead\r\n-- it will return whatever data is available without blocking. It\r\n-- only blocks if there is no data available to read.\r\n}}}\r\nnominolo reports that with ghc-6.12.1 on OSX SL, that the actual behaviour is that `hGet` blocks until all the requested data is available, that is, it does not return a short read.\r\n\r\nSimon clearly thinks that the documented behaviour of hGet is what the behaviour ought to be. In a previous patch to the `ByteString` package he writes:\r\n{{{\r\nMon Mar 22 15:39:14 GMT 2010 Simon Marlow <marlowsd@gmail.com>\r\n * hGetContents: use hGet instead of hGetNonBlocking + hWaitForInput + hIsEOF\r\n \r\n Not only is this cleaner, but it fixes a problem with read binary data\r\n over a pipe, see\r\n http://hackage.haskell.org/trac/ghc/ticket/3808\r\n \r\n The problem is that bytestring normally works fine when the Handle is\r\n not in binary mode, because it uses hGetBuf/hPutBuf which bypass the\r\n encoding layer. That is, except in this one particular case:\r\n hWaitForInput might do some decoding, because it has to determine\r\n whether there are any characters (not bytes) available to be read.\r\n \r\n I imagine hGetNonBlocking was used due to concerns that hGet might\r\n block if there is insufficient data, but that's not the case; hGet\r\n returns a short read if it would otherwise block, and only blocks if\r\n there is no data to read.\r\n}}}\r\n\r\nSo it's not entirely clear what is going on. It's either confusion or a bug (possibly a system-dependent one).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4036Compiled FFI static imports are invalid when imported in GHCI2019-07-07T19:01:00ZjmillikinCompiled FFI static imports are invalid when imported in GHCIWhen I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in \#haskell, and tommd suggested that this might be ...When I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in \#haskell, and tommd suggested that this might be an architecture-dependent error in GHC.
Here's the code used to reproduce the problem. I'm using `sys_siglist` declared in `<signal.h>`, since it's similar to how I originally found the problem, but I suspect this will occur for any static data.
Given the following modules:
```
-- A.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module A where
import Foreign
import Foreign.C
foreign import ccall "&sys_siglist"
siglist_a :: Ptr CString
```
```
-- B.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module B where
import Foreign
import Foreign.C
foreign import ccall "&sys_siglist"
siglist_b :: Ptr CString
```
```
-- Main.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C
import A
import B
foreign import ccall "&sys_siglist"
siglist_main :: Ptr CString
main = do
putStrLn $ "siglist_a = " ++ show siglist_a
putStrLn $ "siglist_b = " ++ show siglist_b
putStrLn $ "siglist_main = " ++ show siglist_main
peekSiglist "a " siglist_a
peekSiglist "b " siglist_b
peekSiglist "main" siglist_main
peekSiglist name siglist = do
ptr <- peekElemOff siglist 2
str <- maybePeek peekCString ptr
putStrLn $ "siglist_" ++ name ++ "[2] = " ++ show str
```
Running the application via GHCI gives correct output:
```
$ runhaskell Main.hs
siglist_a = 0x00007f53a948fe00
siglist_b = 0x00007f53a948fe00
siglist_main = 0x00007f53a948fe00
siglist_a [2] = Just "Interrupt"
siglist_b [2] = Just "Interrupt"
siglist_main[2] = Just "Interrupt"
```
However, if one of them is compiled, its pointer will be invalid:
```
$ ghc -c A.hs
$ runhaskell Main.hs
siglist_a = 0x0000000040378918
siglist_b = 0x00007fe7c029ce00
siglist_main = 0x00007fe7c029ce00
siglist_a [2] = Nothing
siglist_b [2] = Just "Interrupt"
siglist_main[2] = Just "Interrupt"
```
I thought this might be related to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiled FFI static imports are invalid when imported in GHCI","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I try to use the FFI syntax for static storage, only modules running in interpreted mode (ie GHCI) work properly. Compiled modules have invalid pointers, and do not work. I asked in #haskell, and tommd suggested that this might be an architecture-dependent error in GHC.\r\n\r\nHere's the code used to reproduce the problem. I'm using {{{sys_siglist}}} declared in {{{<signal.h>}}}, since it's similar to how I originally found the problem, but I suspect this will occur for any static data.\r\n\r\nGiven the following modules:\r\n\r\n{{{\r\n-- A.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule A where\r\nimport Foreign\r\nimport Foreign.C\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_a :: Ptr CString\r\n}}}\r\n\r\n{{{\r\n-- B.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule B where\r\nimport Foreign\r\nimport Foreign.C\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_b :: Ptr CString\r\n}}}\r\n\r\n{{{\r\n-- Main.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule Main where\r\nimport Foreign\r\nimport Foreign.C\r\nimport A\r\nimport B\r\n\r\nforeign import ccall \"&sys_siglist\"\r\n siglist_main :: Ptr CString\r\n\r\nmain = do\r\n putStrLn $ \"siglist_a = \" ++ show siglist_a\r\n putStrLn $ \"siglist_b = \" ++ show siglist_b\r\n putStrLn $ \"siglist_main = \" ++ show siglist_main\r\n\r\n peekSiglist \"a \" siglist_a\r\n peekSiglist \"b \" siglist_b\r\n peekSiglist \"main\" siglist_main\r\n\r\npeekSiglist name siglist = do\r\n ptr <- peekElemOff siglist 2\r\n str <- maybePeek peekCString ptr\r\n putStrLn $ \"siglist_\" ++ name ++ \"[2] = \" ++ show str\r\n}}}\r\n\r\nRunning the application via GHCI gives correct output:\r\n\r\n{{{\r\n$ runhaskell Main.hs \r\nsiglist_a = 0x00007f53a948fe00\r\nsiglist_b = 0x00007f53a948fe00\r\nsiglist_main = 0x00007f53a948fe00\r\nsiglist_a [2] = Just \"Interrupt\"\r\nsiglist_b [2] = Just \"Interrupt\"\r\nsiglist_main[2] = Just \"Interrupt\"\r\n}}}\r\n\r\nHowever, if one of them is compiled, its pointer will be invalid:\r\n\r\n{{{\r\n$ ghc -c A.hs\r\n$ runhaskell Main.hs \r\nsiglist_a = 0x0000000040378918\r\nsiglist_b = 0x00007fe7c029ce00\r\nsiglist_main = 0x00007fe7c029ce00\r\nsiglist_a [2] = Nothing\r\nsiglist_b [2] = Just \"Interrupt\"\r\nsiglist_main[2] = Just \"Interrupt\"\r\n}}}\r\n\r\nI thought this might be related to ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4019deriving Ord can produce incorrect and inefficient instances2019-07-07T19:01:04Zrl@cse.unsw.edu.auderiving Ord can produce incorrect and inefficient instancesThis bug was spotted by Barak Pearlmutter in http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html.
```
data T = T Double deriving( Eq, Ord )
*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
```
This happens bec...This bug was spotted by Barak Pearlmutter in http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html.
```
data T = T Double deriving( Eq, Ord )
*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
```
This happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving !NaNs always return False, however, compare (arbitrarily) returns GT in this case.
Irrespective of this particular wart, this is what GHC ultimately produces for (\<=):
```
T.$fOrdT_$c<= =
\ (x_ahF :: T.T) (y_ahG :: T.T) ->
case x_ahF of _ { T.T a1_afL ->
case y_ahG of _ { T.T b1_afM ->
case a1_afL of _ { GHC.Types.I# x#_ah1 ->
case b1_afM of _ { GHC.Types.I# y#_ah5 ->
case GHC.Prim.<# x#_ah1 y#_ah5 of _ {
GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;
GHC.Bool.True -> GHC.Bool.True
}
}
}
}
}
```
Note that the definition uses two comparisons even though (\<=) for Double uses just one: (\<=\#\#). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"deriving Ord can produce incorrect and inefficient instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug was spotted by Barak Pearlmutter in http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html.\r\n\r\n{{{\r\ndata T = T Double deriving( Eq, Ord )\r\n\r\n*Main> T (0/0) > T (0/0)\r\nTrue\r\n*Main> (0/0) > (0/0)\r\nFalse\r\n}}}\r\n\r\nThis happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving !NaNs always return False, however, compare (arbitrarily) returns GT in this case.\r\n\r\nIrrespective of this particular wart, this is what GHC ultimately produces for (<=):\r\n\r\n{{{\r\nT.$fOrdT_$c<= =\r\n \\ (x_ahF :: T.T) (y_ahG :: T.T) ->\r\n case x_ahF of _ { T.T a1_afL ->\r\n case y_ahG of _ { T.T b1_afM ->\r\n case a1_afL of _ { GHC.Types.I# x#_ah1 ->\r\n case b1_afM of _ { GHC.Types.I# y#_ah5 ->\r\n case GHC.Prim.<# x#_ah1 y#_ah5 of _ {\r\n GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;\r\n GHC.Bool.True -> GHC.Bool.True\r\n }\r\n }\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nNote that the definition uses two comparisons even though (<=) for Double uses just one: (<=##). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3998strace breaks System.Process(?)2019-07-07T19:01:12Zgreenrdstrace breaks System.Process(?)See http://markmail.org/message/hbf5pf5puvxnxmxo\#query:strace%20greenrd%20ghc+page:1+mid:nfzfholb5gbrsyqm+state:results
Still an issue in 6.12.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
|...See http://markmail.org/message/hbf5pf5puvxnxmxo\#query:strace%20greenrd%20ghc+page:1+mid:nfzfholb5gbrsyqm+state:results
Still an issue in 6.12.1.
<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 | x86 |
</details>
<!-- {"blocked_by":[],"summary":"strace breaks System.Process(?)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"See http://markmail.org/message/hbf5pf5puvxnxmxo#query:strace%20greenrd%20ghc+page:1+mid:nfzfholb5gbrsyqm+state:results\r\n\r\nStill an issue in 6.12.1.","type_of_failure":"OtherFailure","blocking":[]} -->Michael Snoymanmichael@snoyman.comMichael Snoymanmichael@snoyman.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3997Lazy I/O and asynchronous exceptions don't mix well2019-07-07T19:01:12ZSimon MarlowLazy I/O and asynchronous exceptions don't mix wellThis program:
```
import Control.Concurrent
import Control.Exception
main = do
s <- getContents
t <- forkIO $ evaluate (length s) >> return ()
threadDelay 1000
killThread t
print (length s)
```
results in
```
$ ./async ...This program:
```
import Control.Concurrent
import Control.Exception
main = do
s <- getContents
t <- forkIO $ evaluate (length s) >> return ()
threadDelay 1000
killThread t
print (length s)
```
results in
```
$ ./async
async: thread killed
```
when really it should just wait for input.
The problem is #2558, but since I'm not sure that #2558 has a general solution (see comments on that ticket) I thought I'd open a ticket for this specific case. It's amazing nobody has complained about this before.
<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":"Lazy I/O and asynchronous exceptions don't mix well","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Exception\r\n\r\nmain = do\r\n s <- getContents\r\n t <- forkIO $ evaluate (length s) >> return ()\r\n threadDelay 1000\r\n killThread t\r\n print (length s)\r\n}}}\r\n\r\nresults in\r\n\r\n{{{\r\n$ ./async \r\nasync: thread killed\r\n}}}\r\n\r\nwhen really it should just wait for input.\r\n\r\nThe problem is #2558, but since I'm not sure that #2558 has a general solution (see comments on that ticket) I thought I'd open a ticket for this specific case. It's amazing nobody has complained about this before.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/3982Random instance for Double can generate values out of requested range2019-07-07T19:01:16ZmokusRandom instance for Double can generate values out of requested rangeThere appears to be an off-by-one error in randomIvalDouble, causing it to return values outside the requested range one time out of every few billion (exact frequency depending on the bounds of Int):
```
Prelude Control.Monad System.Ra...There appears to be an off-by-one error in randomIvalDouble, causing it to return values outside the requested range one time out of every few billion (exact frequency depending on the bounds of Int):
```
Prelude Control.Monad System.Random> (filter (<= 0) . randomRs (0,1)) `fmap` newStdGen :: IO [Double]
Loading package random-1.0.0.2 ... linking ... done.
[-1.1641532182693481e-10,-1.1641532182693481e-10^CInterrupted.
```
The problem appears to arise because int32Range does not represent the number of possible Int32's returned by the call to randomIvalInteger. Changing the division by int32Range in the definition of scaled_x to division by (int32Range + 1) should fix it. Attached is a darcs patch implementing this change. I don't actually know whether the resulting code reflects the intent of the interface, however. This version will produce the lower bound but not the upper bound.
Additionally, with or without the attached patch the basic structure of the scaling (adding a scaled Int32 to the midpoint of the range) does not play well with floating-point math in the first place: for example, randomR (exp 1, pi :: Double) can return a value one ULP less than 'exp 1'. This could probably be avoided by sampling a Word32 instead of an Int32 and adding the corresponding fraction of the range size to the lower bound.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Random instance for Double can generate values out of requested range","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There appears to be an off-by-one error in randomIvalDouble, causing it to return values outside the requested range one time out of every few billion (exact frequency depending on the bounds of Int):\r\n\r\n\r\n{{{\r\nPrelude Control.Monad System.Random> (filter (<= 0) . randomRs (0,1)) `fmap` newStdGen :: IO [Double]\r\nLoading package random-1.0.0.2 ... linking ... done.\r\n[-1.1641532182693481e-10,-1.1641532182693481e-10^CInterrupted.\r\n\r\n}}}\r\n\r\nThe problem appears to arise because int32Range does not represent the number of possible Int32's returned by the call to randomIvalInteger. Changing the division by int32Range in the definition of scaled_x to division by (int32Range + 1) should fix it. Attached is a darcs patch implementing this change. I don't actually know whether the resulting code reflects the intent of the interface, however. This version will produce the lower bound but not the upper bound.\r\n\r\nAdditionally, with or without the attached patch the basic structure of the scaling (adding a scaled Int32 to the midpoint of the range) does not play well with floating-point math in the first place: for example, randomR (exp 1, pi :: Double) can return a value one ULP less than 'exp 1'. This could probably be avoided by sampling a Word32 instead of an Int32 and adding the corresponding fraction of the range size to the lower bound.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3981Value of function differs for arguments of the same value2019-07-07T19:01:16ZkirstinValue of function differs for arguments of the same valueI'm getting a different result from the same function depending on whether I pass a value or a function that returns that value. This
happens with ghci and ghc.
I would expect to the the same result.
Given:
```
x = [(),(),(),(),(),(),(...I'm getting a different result from the same function depending on whether I pass a value or a function that returns that value. This
happens with ghci and ghc.
I would expect to the the same result.
Given:
```
x = [(),(),(),(),(),(),(),(),(),(),(),(),(),(),()]
choose 0 _ = 0
choose _ 0 = 0
choose n m = factorial n `div` (factorial (n - m) * factorial m)
factorial n = product [1..n]
```
Then:
```
> length x
=> 15
> choose (length x) 2
=> -5
> choose 15 2
=> 105
```
Info:
Debian Squeeze: `Linux velox 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux`
<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":"Value of function differs for arguments of the same value","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":"I'm getting a different result from the same function depending on whether I pass a value or a function that returns that value. This\r\nhappens with ghci and ghc.\r\n\r\nI would expect to the the same result. \r\nGiven:\r\n\r\n{{{\r\nx = [(),(),(),(),(),(),(),(),(),(),(),(),(),(),()]\r\nchoose 0 _ = 0\r\nchoose _ 0 = 0\r\nchoose n m = factorial n `div` (factorial (n - m) * factorial m)\r\nfactorial n = product [1..n]\r\n}}}\r\n\r\nThen:\r\n\r\n{{{\r\n> length x \r\n=> 15\r\n> choose (length x) 2\r\n=> -5\r\n> choose 15 2\r\n=> 105\r\n}}}\r\n\r\n\r\nInfo:\r\n\r\nDebian Squeeze: {{{Linux velox 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3977Support double-byte encodings (Chinese/Japanese/Korean) on Windows2019-07-07T19:01:17Zshelarcy@capella.freemail.ne.jpSupport double-byte encodings (Chinese/Japanese/Korean) on WindowslocaleEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current ...localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current state often causes problem on double-byte encoding environment.
- http://hackage.haskell.org/trac/hackage/ticket/658
- http://hackage.haskell.org/trac/hackage/ticket/659
I know we can solve problem by using hSetEncoding with utf8 or othere UTF-\* encodings. But it's not good solution.
According to previous Windows patch, GHC.IO.Encoding.CodePage.Table doesn't support double-byte encodings because Windows' shared library support doesn't work.
- http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html
- http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz
```
Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since
including those codepages would increase the table size to 400KB. It will be
straightforward to implement them once the work on library DLLs is finished.
```
I think Windows' shared library support works now. Because #3879 is closed.
So, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | shelarcy@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support double-byte encodings (Chinese/Japanese/Korean) on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["shelarcy@gmail.com"],"type":"FeatureRequest","description":"localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current state often causes problem on double-byte encoding environment.\r\n\r\n * http://hackage.haskell.org/trac/hackage/ticket/658\r\n * http://hackage.haskell.org/trac/hackage/ticket/659\r\n\r\nI know we can solve problem by using hSetEncoding with utf8 or othere UTF-* encodings. But it's not good solution.\r\n\r\nAccording to previous Windows patch, GHC.IO.Encoding.CodePage.Table doesn't support double-byte encodings because Windows' shared library support doesn't work.\r\n\r\n * http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html\r\n * http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz\r\n\r\n{{{\r\nCurrently we do not support double-byte encodings (Chinese/Japanese/Korean), since\r\nincluding those codepages would increase the table size to 400KB. It will be\r\nstraightforward to implement them once the work on library DLLs is finished.\r\n}}}\r\n\r\nI think Windows' shared library support works now. Because #3879 is closed.\r\n\r\nSo, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?","type_of_failure":"OtherFailure","blocking":[]} -->batterseapowerbatterseapowerhttps://gitlab.haskell.org/ghc/ghc/-/issues/3976'+RTS -S' reports negative allocation.2019-07-07T19:01:17ZWolfram Kahl'+RTS -S' reports negative allocation.While running Agda with `+RTS -S`, I see a lot of negative heap allocation reported, for example:
```
6967252 1723140 163854188 0.04 0.04 19.39 19.86 0 0 (Gen: 0)
Skipping Categoric.OCC.Props.Mapping (/var/tmp/kahl/svn...While running Agda with `+RTS -S`, I see a lot of negative heap allocation reported, for example:
```
6967252 1723140 163854188 0.04 0.04 19.39 19.86 0 0 (Gen: 0)
Skipping Categoric.OCC.Props.Mapping (/var/tmp/kahl/svn/RATH/trunk/Agda/Categoric/OCC/Props/Mapping.agdai).
Skipping Categoric.OCC (/var/tmp/kahl/svn/RATH/trunk/Agda/Categoric/OCC.agdai).
-1239169216 10322552 173302476 0.22 0.22 31.17 33.44 0 0 (Gen: 0)
-1255628852 13628520 179169592 0.26 0.26 42.57 44.88 0 1 (Gen: 0)
-1260863492 9986512 182103292 0.16 0.16 53.56 56.22 0 0 (Gen: 0)
-1259733000 8999552 188116056 0.20 0.21 64.50 67.18 0 0 (Gen: 0)
```
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"'+RTS -S' reports negative allocation.","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nWhile running Agda with {{{+RTS -S}}}, I see a lot of negative heap allocation reported, for example:\r\n{{{\r\n 6967252 1723140 163854188 0.04 0.04 19.39 19.86 0 0 (Gen: 0)\r\nSkipping Categoric.OCC.Props.Mapping (/var/tmp/kahl/svn/RATH/trunk/Agda/Categoric/OCC/Props/Mapping.agdai).\r\nSkipping Categoric.OCC (/var/tmp/kahl/svn/RATH/trunk/Agda/Categoric/OCC.agdai).\r\n-1239169216 10322552 173302476 0.22 0.22 31.17 33.44 0 0 (Gen: 0)\r\n-1255628852 13628520 179169592 0.26 0.26 42.57 44.88 0 1 (Gen: 0)\r\n-1260863492 9986512 182103292 0.16 0.16 53.56 56.22 0 0 (Gen: 0)\r\n-1259733000 8999552 188116056 0.20 0.21 64.50 67.18 0 0 (Gen: 0)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3975filepath: normalise trailing dot2019-07-07T19:01:17Zconradfilepath: normalise trailing dotThis darcs patch modifies the behaviour of normalise to handle
trailing dots in a path. The previous behaviour yielded this:
```
Prelude System.FilePath> normalise "../."
"../."
Prelude System.FilePath> normalise ".././"
".././"
Prelude...This darcs patch modifies the behaviour of normalise to handle
trailing dots in a path. The previous behaviour yielded this:
```
Prelude System.FilePath> normalise "../."
"../."
Prelude System.FilePath> normalise ".././"
".././"
Prelude System.FilePath> normalise ".././.."
"../.."
```
This patch modifies dropDots such that the check for (".":\[\]) only
occurs once for the path, after which a driver function dropDots' is
used which skips this check. Hence "." can be removed from the end of
a longer path, but a path of just "." is unchanged.
http://www.haskell.org/pipermail/libraries/2010-February/013030.html
<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":"filepath: normalise trailing dot","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["filepath","normalise"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This darcs patch modifies the behaviour of normalise to handle\r\ntrailing dots in a path. The previous behaviour yielded this:\r\n\r\n{{{\r\nPrelude System.FilePath> normalise \"../.\"\r\n\"../.\"\r\nPrelude System.FilePath> normalise \".././\"\r\n\".././\"\r\nPrelude System.FilePath> normalise \".././..\"\r\n\"../..\"\r\n}}}\r\n\r\nThis patch modifies dropDots such that the check for (\".\":[]) only\r\noccurs once for the path, after which a driver function dropDots' is\r\nused which skips this check. Hence \".\" can be removed from the end of\r\na longer path, but a path of just \".\" is unchanged.\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2010-February/013030.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/3974Duplicate bug: (see #3975) filepath: normalise trailing dot2019-07-07T19:01:17ZconradDuplicate bug: (see #3975) filepath: normalise trailing dotThis darcs patch modifies the behaviour of normalise to handle
trailing dots in a path. The previous behaviour yielded this:
Prelude System.FilePath\> normalise "../."
"../."
Prelude System.FilePath\> normalise ".././"
".././"
Prelude S...This darcs patch modifies the behaviour of normalise to handle
trailing dots in a path. The previous behaviour yielded this:
Prelude System.FilePath\> normalise "../."
"../."
Prelude System.FilePath\> normalise ".././"
".././"
Prelude System.FilePath\> normalise ".././.."
"../.."
This patch modifies dropDots such that the check for (".":\[\]) only
occurs once for the path, after which a driver function dropDots' is
used which skips this check. Hence "." can be removed from the end of
a longer path, but a path of just "." is unchanged.
http://www.haskell.org/pipermail/libraries/2010-February/013030.html
<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":"filepath: normalise trailing dot","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["filepath","normalise"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This darcs patch modifies the behaviour of normalise to handle\r\ntrailing dots in a path. The previous behaviour yielded this:\r\n\r\nPrelude System.FilePath> normalise \"../.\"\r\n\"../.\"\r\nPrelude System.FilePath> normalise \".././\"\r\n\".././\"\r\nPrelude System.FilePath> normalise \".././..\"\r\n\"../..\"\r\n\r\nThis patch modifies dropDots such that the check for (\".\":[]) only\r\noccurs once for the path, after which a driver function dropDots' is\r\nused which skips this check. Hence \".\" can be removed from the end of\r\na longer path, but a path of just \".\" is unchanged.\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2010-February/013030.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://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/3916incorrect kind inference in template haskell2019-07-07T19:01:33Znfrisbyincorrect kind inference in template haskellIt looks like a foldl needs to be changed to a foldr somewhere in the code that translates results from GHC's kind inference to the Template Haskell Kind data type.
Given this data declaration:
```
data F f a = F (f a a a a)
```
the ...It looks like a foldl needs to be changed to a foldr somewhere in the code that translates results from GHC's kind inference to the Template Haskell Kind data type.
Given this data declaration:
```
data F f a = F (f a a a a)
```
the kind ascribed to `f`, as provided in the `Info` data structure resultant of reifying `F`, is
```
(((* -> *) -> *) -> *) -> *
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"incorrect kind inference in template haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["kinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It looks like a foldl needs to be changed to a foldr somewhere in the code that translates results from GHC's kind inference to the Template Haskell Kind data type.\r\n\r\nGiven this data declaration:\r\n\r\n{{{\r\ndata F f a = F (f a a a a) \r\n}}}\r\n\r\nthe kind ascribed to {{{f}}}, as provided in the {{{Info}}} data structure resultant of reifying {{{F}}}, is\r\n\r\n{{{\r\n(((* -> *) -> *) -> *) -> *\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3914handleToFd closes Fd when Handle is GC'd2019-07-07T19:01:34ZdandersonhandleToFd closes Fd when Handle is GC'dThe following reproduction case creates a TCP server that will read forever from the first client that connects to it. Having a client do so (eg. with `cat /dev/urandom | nc localhost 4242`) will fairly rapidly cause the server to crash ...The following reproduction case creates a TCP server that will read forever from the first client that connects to it. Having a client do so (eg. with `cat /dev/urandom | nc localhost 4242`) will fairly rapidly cause the server to crash with a "Bad file descriptor" exception.
```
module Main where
import Control.Monad(forever)
import Network
import System.IO
import System.Posix.IO(fdToHandle, handleToFd)
main = withSocketsDo $ do
(hdl, _, _) <- listenOn (PortNumber 4242) >>= accept
newHdl <- handleToFd hdl >>= fdToHandle
forever $ hGetChar newHdl >>= putChar >> hFlush stdout
```
My hunch on the cause is that handleToFd doesn't let go of the underlying system file descriptor when it returns the Fd. Later, when the GC runs, it collects hdl and incorrectly closes the system fd, now in use by newHdl.
An strace of the server binary confirms this sequence of events (shortened to the essentials, but the sequencing is as shown - 4 is the hdl/newHdl file descriptor):
```
...
select(5, [4], [], NULL, {134, 217727}) = 1 (in [4], left {134, 203169})
...
close(4) = 0
...
select(5, [4], [], NULL, {0, 0}) = -1 EBADF (Bad file descriptor)
write(2, "Minimal: ", 9Minimal: ) = 9
write(2, "<file descriptor: 4>: hGetChar: "..., 70<file descriptor: 4>: hGetChar: invalid argument (Bad file descriptor)) = 70
```
Running the binary with '+RTS -s' also shows that some GC passes did occur during the short lifetime of the program, further pointing the finger at incorrect collection of the system fd.
While the reproduction recipe seems silly, the handleToFd \>\>= fdToHandle scenario is actually very useful when doing low level FFI. The real code where I hit this bug is http://bitbucket.org/danderson/tunskell/src/330b5edba1dc/Ioctl.hsc . I extract the Fd in order to make an ioctl() call, then return a new Handle of that Fd after the ioctl() finishes. Using this pattern, the code reading from that tweaked Handle dies after the first GC pass.
<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":"handleToFd closes Fd when Handle is GC'd","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":"The following reproduction case creates a TCP server that will read forever from the first client that connects to it. Having a client do so (eg. with `cat /dev/urandom | nc localhost 4242`) will fairly rapidly cause the server to crash with a \"Bad file descriptor\" exception.\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Control.Monad(forever)\r\nimport Network\r\nimport System.IO\r\nimport System.Posix.IO(fdToHandle, handleToFd)\r\n\r\nmain = withSocketsDo $ do\r\n (hdl, _, _) <- listenOn (PortNumber 4242) >>= accept\r\n newHdl <- handleToFd hdl >>= fdToHandle\r\n forever $ hGetChar newHdl >>= putChar >> hFlush stdout\r\n}}}\r\n\r\nMy hunch on the cause is that handleToFd doesn't let go of the underlying system file descriptor when it returns the Fd. Later, when the GC runs, it collects hdl and incorrectly closes the system fd, now in use by newHdl.\r\n\r\nAn strace of the server binary confirms this sequence of events (shortened to the essentials, but the sequencing is as shown - 4 is the hdl/newHdl file descriptor):\r\n\r\n{{{\r\n...\r\nselect(5, [4], [], NULL, {134, 217727}) = 1 (in [4], left {134, 203169})\r\n...\r\nclose(4) = 0\r\n...\r\nselect(5, [4], [], NULL, {0, 0}) = -1 EBADF (Bad file descriptor)\r\nwrite(2, \"Minimal: \", 9Minimal: ) = 9\r\nwrite(2, \"<file descriptor: 4>: hGetChar: \"..., 70<file descriptor: 4>: hGetChar: invalid argument (Bad file descriptor)) = 70\r\n}}}\r\n\r\nRunning the binary with '+RTS -s' also shows that some GC passes did occur during the short lifetime of the program, further pointing the finger at incorrect collection of the system fd.\r\n\r\nWhile the reproduction recipe seems silly, the handleToFd >>= fdToHandle scenario is actually very useful when doing low level FFI. The real code where I hit this bug is http://bitbucket.org/danderson/tunskell/src/330b5edba1dc/Ioctl.hsc . I extract the Fd in order to make an ioctl() call, then return a new Handle of that Fd after the ioctl() finishes. Using this pattern, the code reading from that tweaked Handle dies after the first GC pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://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/3910+RTS options introduce a security problem for, e.g., setuid binaries2019-07-07T19:01:35ZAnders Kaseorg+RTS options introduce a security problem for, e.g., setuid binariesThe fact that every ghc-compiled program accepts +RTS options could be a security problem in several contexts. For example, if you compile a “Hello, world!” program and make it setuid root, any user can now overwrite any file on the syst...The fact that every ghc-compiled program accepts +RTS options could be a security problem in several contexts. For example, if you compile a “Hello, world!” program and make it setuid root, any user can now overwrite any file on the system using root privileges: `hello +RTS -t/etc/passwd`.
The GHCRTS environment variable has the same problem.
One should not need to have to know about these obscure features to write a secure program that accepts untrusted arguments.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"+RTS options introduce a security problem for, e.g., setuid binaries","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The fact that every ghc-compiled program accepts +RTS options could be a security problem in several contexts. For example, if you compile a “Hello, world!” program and make it setuid root, any user can now overwrite any file on the system using root privileges: `hello +RTS -t/etc/passwd`.\r\n\r\nThe GHCRTS environment variable has the same problem.\r\n\r\nOne should not need to have to know about these obscure features to write a secure program that accepts untrusted arguments.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3878doesFileExist doesn't work for some /dev files in ghc 6.122019-07-07T19:01:43ZmarcotmarcotdoesFileExist doesn't work for some /dev files in ghc 6.12Hi. I've noticed this with a program that checks for a lvm image. Here's the situation:
```
Prelude System.Directory> doesFileExist "/dev/null"
True
Prelude System.Directory> doesFileExist "/dev/stdin"
True
Prelude System.Directory> doe...Hi. I've noticed this with a program that checks for a lvm image. Here's the situation:
```
Prelude System.Directory> doesFileExist "/dev/null"
True
Prelude System.Directory> doesFileExist "/dev/stdin"
True
Prelude System.Directory> doesFileExist "/dev/sda0"
False
Prelude System.Directory> doesFileExist "/dev/zezinho/sid"
False
```
All of these files exist in my system:
```
marcot@zezinho:/dev$ ls -l null sda1 stdin zezinho/sid /proc/self/fd/0 mapper/zezinho-sid /dev/pts/5
crw--w---- 1 marcot tty 136, 5 Fev 12 09:09 /dev/pts/5
brw-rw---- 1 root disk 254, 4 Fev 12 08:55 mapper/zezinho-sid
crw-rw-rw- 1 root root 1, 3 Fev 12 08:33 null
lrwx------ 1 marcot marcot 64 Fev 12 09:09 /proc/self/fd/0 -> /dev/pts/5
brw-rw---- 1 root disk 8, 1 Fev 12 08:55 sda1
lrwxrwxrwx 1 root root 15 Fev 12 08:33 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 21 Fev 12 08:55 zezinho/sid -> ../mapper/zezinho-sid
```6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3802:main in GHCi doesn't do getArgs wildcard expansion2019-07-07T19:02:06ZNeil Mitchell:main in GHCi doesn't do getArgs wildcard expansionIn GHCi, from a current directory containing some Haskell files:
```
ghci> import System
ghci> let main = print =<< getArgs
ghci> :main *.hs
["*.hs"]
```
I would have expected `["foo.hs","bar.hs"]`. Running the same thing from the comm...In GHCi, from a current directory containing some Haskell files:
```
ghci> import System
ghci> let main = print =<< getArgs
ghci> :main *.hs
["*.hs"]
```
I would have expected `["foo.hs","bar.hs"]`. Running the same thing from the command line (compiled or through runhaskell) gives the expected behaviour.
<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":":main in GHCi doesn't do getArgs wildcard expansion","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":"In GHCi, from a current directory containing some Haskell files:\r\n\r\n{{{\r\nghci> import System\r\nghci> let main = print =<< getArgs\r\nghci> :main *.hs\r\n[\"*.hs\"]\r\n}}}\r\n\r\nI would have expected {{{[\"foo.hs\",\"bar.hs\"]}}}. Running the same thing from the command line (compiled or through runhaskell) gives the expected behaviour.","type_of_failure":"OtherFailure","blocking":[]} -->