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