GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:17:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/431runInteractiveProcess and closed stdin.2019-07-07T19:17:59ZnobodyrunInteractiveProcess and closed stdin.```
Hello,
The System.Process.runInteractiveProcess function
doesn't seem to provide the child process with a stdin
handle when the parent's stdin is closed. Below is a
small example:
import System.Process
import Control.Concurrent
imp...```
Hello,
The System.Process.runInteractiveProcess function
doesn't seem to provide the child process with a stdin
handle when the parent's stdin is closed. Below is a
small example:
import System.Process
import Control.Concurrent
import System.IO
main = do
hClose stdin -- everything works as expected if the
handle isn't closed.
putStrLn "Running cat ..."
(inp, out, err, pid) <- runInteractiveProcess "cat"
[] Nothing Nothing
forkIO (hPutStrLn inp "foo" >> hClose inp)
forkIO (putStrLn =<< hGetContents out)
forkIO (putStrLn =<< hGetContents err)
-- Don't want to deal with waitForProcess and
-threaded right now.
threadDelay 1000000
return ()
Running this example produces the error
% ghc Run.hs -o run
% ./run
Running cat ...
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
I think the bug is in
fptools/libraries/base/cbits/runProcess.c:
//...
pipe(fdStdInput);
//...
dup2 (fdStdInput[0], STDIN_FILENO);
/...
close(fdStdInput[0]);
//...
pipe(...) will assign the lowest available file
descriptors, i.e. 0 if stdin is closed. The dup2 won't
do anything, since src and dest fds are identical, so
close(...) will close the child's stdin immediately.
% uname -a
Linux mthomas 2.6.12 #2 Thu Jul 21 07:51:44 EDT 2005
i686 GNU/Linux
% ghc --version
The Glorious Glasgow Haskell Compilation System,
version 6.5.20050728
Thanks,
-- Thomas Jäger
```https://gitlab.haskell.org/ghc/ghc/-/issues/2401aborting an STM transaction should throw an exception2019-07-07T19:08:45Zsclvaborting an STM transaction should throw an exceptionThe attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place...The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unsafeIOToSTM hangs with 64 bit multicore.","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2615ghci doesn't play nice with linker scripts2021-12-25T17:48:48ZAlecBerrymanghci doesn't play nice with linker scriptsI'm trying to use HsHyperEstraier with ghci. I can compile and run the included examples, but when I run them in ghci, I see:
```
$ ghci
GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... ...I'm trying to use HsHyperEstraier with ghci. I can compile and run the included examples, but when I run them in ghci, I see:
```
$ ghci
GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :l HelloWorld.hs
[1 of 1] Compiling Main ( HelloWorld.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
[...]
Loading package HsHyperEstraier-0.2.1 ... can't load .so/.DLL for: c
(/usr/lib/libc.so: invalid ELF header)
```
I see a similar error message if I specify '-package HsHyperEstraier' on the command line.
I did some looking and came up with these messages:
http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006632.html
http://www.nabble.com/RE:-idea-to-allow-ghci-to-use-a-different-libs-list-p1830432.html
Debian's /usr/lib/libc.so is indeed a GNU linker script, not an actual shared library. If I remove all the libraries in HsHyperEstraier's \~/.ghc/.../package.conf that are linker scripts (pthreads and c), it loads up fine.
Could ghci either recognize or ignore linker scripts?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"ghci doesn't play nice with linker scripts","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I'm trying to use HsHyperEstraier with ghci. I can compile and run the included examples, but when I run them in ghci, I see:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :l HelloWorld.hs\r\n[1 of 1] Compiling Main ( HelloWorld.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\n[...]\r\nLoading package HsHyperEstraier-0.2.1 ... can't load .so/.DLL for: c\r\n(/usr/lib/libc.so: invalid ELF header)\r\n}}}\r\n\r\nI see a similar error message if I specify '-package HsHyperEstraier' on the command line.\r\n\r\nI did some looking and came up with these messages:\r\n\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006632.html\r\nhttp://www.nabble.com/RE:-idea-to-allow-ghci-to-use-a-different-libs-list-p1830432.html\r\n\r\nDebian's /usr/lib/libc.so is indeed a GNU linker script, not an actual shared library. If I remove all the libraries in HsHyperEstraier's ~/.ghc/.../package.conf that are linker scripts (pthreads and c), it loads up fine.\r\n\r\nCould ghci either recognize or ignore linker scripts?","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/3516[PATCH] ppc64: broken 'foreign import wrapper'2019-07-07T19:03:32ZSergei Trofimovich[PATCH] ppc64: broken 'foreign import wrapper'Attaching simple testcase failing horribly on ppc64:
amd64 test output:
```
$ ./dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback functio...Attaching simple testcase failing horribly on ppc64:
amd64 test output:
```
$ ./dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:H(72)H(33)[result = 735]
TEST PASSED
```
ppc64 test output:
```
$ dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:[result = 105]
Segmentation fault
```
As you see **C call with registered Hs-C callback function** called not a registered function, but something strange. There is no even registered callback (glo_cb == 0).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ppc64: broken 'foreign import wrapper'","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["ffi,","wrapper"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attaching simple testcase failing horribly on ppc64:\r\n\r\namd64 test output:\r\n{{{\r\n$ ./dist/build/fct/fct\r\nC call:[result = 105]\r\n\r\nC call with registered C callback function:C(72)C(33)[result = 735]\r\n\r\nC call with registered Hs-C callback function:H(72)H(33)[result = 735]\r\n\r\nTEST PASSED\r\n}}}\r\n\r\nppc64 test output:\r\n{{{\r\n$ dist/build/fct/fct\r\nC call:[result = 105]\r\n\r\nC call with registered C callback function:C(72)C(33)[result = 735]\r\n\r\nC call with registered Hs-C callback function:[result = 105]\r\n\r\nSegmentation fault\r\n\r\n}}}\r\n\r\nAs you see '''C call with registered Hs-C callback function''' called not a registered function, but something strange. There is no even registered callback (glo_cb == 0).","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2https://gitlab.haskell.org/ghc/ghc/-/issues/3710WriteFile: invalid argument (The handle is invalid.)2019-07-07T19:02:40ZdheringtonWriteFile: invalid argument (The handle is invalid.)I defined an interface to the Windows WriteFile routine to allow specification of the starting address for the write. It generally works, but when called repeatedly it reproducibly generates an unexpected error at runtime:
> WriteFile:...I defined an interface to the Windows WriteFile routine to allow specification of the starting address for the write. It generally works, but when called repeatedly it reproducibly generates an unexpected error at runtime:
> WriteFile: invalid argument (The handle is invalid.)
I suspect that garbage collection is involved because
> Bug1 2 fum 1000
fails, but
> Bug1 +RTS -H1g -RTS 2 fum 1000
(which serves, I think, to disable garbage collection for my test) succeeds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| 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":"WriteFile: invalid argument (The handle is invalid.)","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":["collector","garbage"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I defined an interface to the Windows WriteFile routine to allow specification of the starting address for the write. It generally works, but when called repeatedly it reproducibly generates an unexpected error at runtime:\r\n\r\n WriteFile: invalid argument (The handle is invalid.)\r\n\r\nI suspect that garbage collection is involved because\r\n Bug1 2 fum 1000\r\nfails, but\r\n Bug1 +RTS -H1g -RTS 2 fum 1000\r\n(which serves, I think, to disable garbage collection for my test) succeeds.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3731SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class ex...2019-07-07T19:02:33ZdsfSYB gone wild - mysterious <<loop>> in code derived from an syb-with-class example(From http://www.haskell.org/pipermail/haskell-cafe/2009-December/070193.html)
In the attached code,
1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine
1. if you change th...(From http://www.haskell.org/pipermail/haskell-cafe/2009-December/070193.html)
In the attached code,
1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine
1. if you change the gunfold instance for Proposition to, error "gunfold" it stops hanging -- even though this code is never called.
1. if you change, ( Data ctx \[Expression\], Sat (ctx Expression) =\> Data ctx Expression, to (Data ctx Expression, ....) =\> ... it stops hanging.
If someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| 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":"SYB gone wild - mysterious <<loop>> in code derived from an syb-with-class example","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(From http://www.haskell.org/pipermail/haskell-cafe/2009-December/070193.html)\r\n\r\nIn the attached code,\r\n\r\n 1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine\r\n 2. if you change the gunfold instance for Proposition to, error \"gunfold\" it stops hanging -- even though this code is never called.\r\n 3. if you change, ( Data ctx [Expression], Sat (ctx Expression) => Data ctx Expression, to (Data ctx Expression, ....) => ... it stops hanging.\r\n\r\nIf someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there...\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3734overlapping orphan instances behave like incoherent without warning/error2019-07-07T19:02:32ZTomáš Janoušekoverlapping orphan instances behave like incoherent without warning/errorConsider these three modules:
```
module A where
class (Show a) => A a
data A' = A' deriving (Show)
instance A A'
data A'' = A'' deriving (Show)
instance A A''
print_a :: (A a) => a -> IO ()
print_a a = print a
```
```
{-# LANGUAGE...Consider these three modules:
```
module A where
class (Show a) => A a
data A' = A' deriving (Show)
instance A A'
data A'' = A'' deriving (Show)
instance A A''
print_a :: (A a) => a -> IO ()
print_a a = print a
```
```
{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module B where
import A
data B a = B a deriving (Show)
instance (A a) => A (B a)
```
```
{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module Main where
import A
import B
instance Show (B A') where
show _ = "kokodak"
instance Show (B A'') where
show _ = "brekeke"
instance A (B A'')
main :: IO ()
main = do
print (B A')
print_a (B A')
putStrLn ""
print (B A'')
print_a (B A'')
```
Without understanding a thing about dictionaries, I would expect that if this actually compiles (which I now understand it should not), I'd get `"kokodak kokodak brekeke brekeke"` as output, but I got `"kokodak B A' brekeke brekeke"` instead.
I figured that even though I redefined `Show (B A')`, the `A (B a)` instance was defined in module `B` and consisted of the original `Show` dictionary. If I move the `Show (B A')` instance to module B, ghc complains that the definition of `A (B a)` depends on the instatiation of `a` and refuses to compile it, unless I enable `IncoherentInstances`.
The problem here is that if the `Show (B A')` instance is orphan, I get the `IncoherentInstances` behaviour for free without any warning or error, giving me the false feeling that the code is actually OK. Is it possible that ghc gives an error in this case, and may the documentation mention that Overlapping + Orphan =\> Incoherent?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"overlapping orphan instances behave like incoherent without warning/error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider these three modules:\r\n\r\n{{{\r\nmodule A where\r\n\r\nclass (Show a) => A a\r\n\r\ndata A' = A' deriving (Show)\r\ninstance A A'\r\n\r\ndata A'' = A'' deriving (Show)\r\ninstance A A''\r\n\r\nprint_a :: (A a) => a -> IO ()\r\nprint_a a = print a\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}\r\nmodule B where\r\n\r\nimport A\r\n\r\ndata B a = B a deriving (Show)\r\ninstance (A a) => A (B a)\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}\r\nmodule Main where\r\n\r\nimport A\r\nimport B\r\n\r\ninstance Show (B A') where\r\n show _ = \"kokodak\"\r\n\r\ninstance Show (B A'') where\r\n show _ = \"brekeke\"\r\n\r\ninstance A (B A'')\r\n\r\nmain :: IO ()\r\nmain = do\r\n print (B A')\r\n print_a (B A')\r\n putStrLn \"\"\r\n print (B A'')\r\n print_a (B A'')\r\n}}}\r\n\r\nWithout understanding a thing about dictionaries, I would expect that if this actually compiles (which I now understand it should not), I'd get `\"kokodak kokodak brekeke brekeke\"` as output, but I got `\"kokodak B A' brekeke brekeke\"` instead.\r\n\r\nI figured that even though I redefined `Show (B A')`, the `A (B a)` instance was defined in module `B` and consisted of the original `Show` dictionary. If I move the `Show (B A')` instance to module B, ghc complains that the definition of `A (B a)` depends on the instatiation of `a` and refuses to compile it, unless I enable `IncoherentInstances`.\r\n\r\nThe problem here is that if the `Show (B A')` instance is orphan, I get the `IncoherentInstances` behaviour for free without any warning or error, giving me the false feeling that the code is actually OK. Is it possible that ghc gives an error in this case, and may the documentation mention that Overlapping + Orphan => Incoherent?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3745Non-deterministic behavior with FFI2019-07-07T19:02:29ZgchrupalaNon-deterministic behavior with FFII have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is a...I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine.
The same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC.
I attach a simplified extract of the code which will show the problem.
I included:
- c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation
- test.hs : Haskell program which calls the C++ function via FFI
- test.cpp : Equivalent C++ program which calls the same C++ function
- run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results
- train : data file which the programs process
I compiled using GHC 6.10.4 like this:
```
ghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++
```
To see the problem execute:
```
./run.sh ./test-ghc-6.10.4
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Non-deterministic behavior with FFI","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine.\r\n\r\nThe same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC.\r\n\r\nI attach a simplified extract of the code which will show the problem. \r\n\r\nI included: \r\n\r\n* c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation\r\n\r\n* test.hs : Haskell program which calls the C++ function via FFI\r\n\r\n* test.cpp : Equivalent C++ program which calls the same C++ function\r\n\r\n* run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results\r\n\r\n* train : data file which the programs process\r\n\r\n\r\nI compiled using GHC 6.10.4 like this:\r\n{{{\r\nghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++\r\n}}}\r\n\r\nTo see the problem execute:\r\n{{{\r\n./run.sh ./test-ghc-6.10.4\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2https://gitlab.haskell.org/ghc/ghc/-/issues/3747getDirectoryContents yields wrong results2019-07-07T19:02:28ZMeddixgetDirectoryContents yields wrong resultsExecuting getDirectoryContents on "c:" gives the contents of the current directory.\[\[BR\]\]
The following program prints always True:
```
module Main (main) where
import System.Directory
main :: IO ()
main = do
rootContents <- get...Executing getDirectoryContents on "c:" gives the contents of the current directory.\[\[BR\]\]
The following program prints always True:
```
module Main (main) where
import System.Directory
main :: IO ()
main = do
rootContents <- getDirectoryContents "c:"
currContents <- getCurrentDirectory >>= getDirectoryContents
putStrLn . show $ currContents == rootContents
```
Thanks
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.4 |
| 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":"getDirectoryContents yields wrong results","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Executing getDirectoryContents on \"c:\" gives the contents of the current directory.[[BR]]\r\nThe following program prints always True:\r\n\r\n\r\n{{{\r\n\r\nmodule Main (main) where\r\n\r\nimport System.Directory\r\n\r\nmain :: IO ()\r\nmain = do\r\n rootContents <- getDirectoryContents \"c:\"\r\n currContents <- getCurrentDirectory >>= getDirectoryContents\r\n putStrLn . show $ currContents == rootContents\r\n\r\n}}}\r\n\r\nThanks","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3800sizeofByteArray# returns allocated words, not requested length in bytes2019-07-07T19:02:06ZAntoineLattersizeofByteArray# returns allocated words, not requested length in bytesA byte array allocated with (`GHC.Prim.newByteArray# 7`) will report it's size as '8' - that is, the stored size in `StgArrWords` is the number of allocated words, not the number of requested bytes.
This menas that if I want to a `GHC.P...A byte array allocated with (`GHC.Prim.newByteArray# 7`) will report it's size as '8' - that is, the stored size in `StgArrWords` is the number of allocated words, not the number of requested bytes.
This menas that if I want to a `GHC.Prim.ByteArray#` or `MutableByteArray#` as an array type, I need a separate length fields.
See also: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018199.htmlhttps://gitlab.haskell.org/ghc/ghc/-/issues/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":[]} -->https://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/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/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/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/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/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/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/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/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.1