GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:52:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/6106GHCi does not always detect when modules become stale during compilation2019-07-07T18:52:08ZSimon Hengelsol@typeful.netGHCi does not always detect when modules become stale during compilationHere is a conceived example that illustrates the issue.
File `Foo.hs` is changed after it's content has been read in the Haskell pre-processor phase.
{{{
\#!/bin/bash
\#
\# file preprocess.sh
\#
cat $2 \> $3
sleep 1
touch $1
}}}
```
-...Here is a conceived example that illustrates the issue.
File `Foo.hs` is changed after it's content has been read in the Haskell pre-processor phase.
{{{
\#!/bin/bash
\#
\# file preprocess.sh
\#
cat $2 \> $3
sleep 1
touch $1
}}}
```
-- file Foo.hs
{-# OPTIONS_GHC -F -pgmF ./preprocess.sh #-}
module Foo where
```
```
$ ghci Foo.hs
*Foo> :reload
```
Expected result: Foo.hs is recompiled on :reload
Actual result: Nothing is recompiled on :reload
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"GHCi does not always detect when modules become stale during compilation","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a conceived example that illustrates the issue.\r\n\r\nFile {{{Foo.hs}}} is changed after it's content has been read in the Haskell pre-processor phase.\r\n\r\n{{{\r\n#!/bin/bash\r\n#\r\n# file preprocess.sh\r\n#\r\ncat $2 > $3\r\nsleep 1\r\ntouch $1\r\n}}}\r\n\r\n{{{\r\n-- file Foo.hs\r\n{-# OPTIONS_GHC -F -pgmF ./preprocess.sh #-}\r\nmodule Foo where\r\n}}}\r\n\r\n{{{\r\n$ ghci Foo.hs\r\n*Foo> :reload\r\n}}}\r\n\r\nExpected result: Foo.hs is recompiled on :reload\r\n\r\nActual result: Nothing is recompiled on :reload","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6105GHCi does no respect -fforce-recomp2019-07-07T18:52:08ZSimon Hengelsol@typeful.netGHCi does no respect -fforce-recompTo my delightful surprise `ghc --make` respects `-fforce-recomp`, when given in a source file with `OPTIONS_GHC`.
But `GHCi` does not respect it.
Steps to reproduce:
```
-- file Bar.hs
{-# OPTIONS_GHC -fforce-recomp #-}
module Bar whe...To my delightful surprise `ghc --make` respects `-fforce-recomp`, when given in a source file with `OPTIONS_GHC`.
But `GHCi` does not respect it.
Steps to reproduce:
```
-- file Bar.hs
{-# OPTIONS_GHC -fforce-recomp #-}
module Bar where
```
```
$ ghci Bar.hs
*Bar> :reload
```
Expected result: `Bar.hs` is recompiled on `:reload`
Actual result: Nothing is recompiled on `:reload`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"GHCi does no respect -fforce-recomp","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To my delightful surprise {{{ghc --make}}} respects {{{-fforce-recomp}}}, when given in a source file with {{{OPTIONS_GHC}}}.\r\n\r\nBut {{{GHCi}}} does not respect it.\r\n\r\nSteps to reproduce:\r\n\r\n{{{\r\n-- file Bar.hs\r\n{-# OPTIONS_GHC -fforce-recomp #-}\r\nmodule Bar where\r\n}}}\r\n\r\n{{{\r\n$ ghci Bar.hs\r\n*Bar> :reload\r\n}}}\r\n\r\nExpected result: {{{Bar.hs}}} is recompiled on {{{:reload}}}\r\n\r\nActual result: Nothing is recompiled on {{{:reload}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6103Interrupted program cannot produce biographical heap profile2019-07-07T18:52:09ZHiromi IshiiInterrupted program cannot produce biographical heap profileIf I interrupt program running with "+RTS -p -hb" option, the program aborts with message below and I could only get empty heap profile.
Minimal case is below:
```
module Main where
main :: IO ()
main = print $ sum [1..10000000000]
```...If I interrupt program running with "+RTS -p -hb" option, the program aborts with message below and I could only get empty heap profile.
Minimal case is below:
```
module Main where
main :: IO ()
main = print $ sum [1..10000000000]
```
I compiled this code with "-prof -rtsopts" options, ran the program and then interrupt after several seconds.
```
$ ghc http-biographic-profile.hs -prof -rtsopts
[1 of 1] Compiling Main ( http-biographic-profile.hs, http-biographic-profile.o )
Linking biographic-profile ...
$ ./http-biographic-profile +RTS -hb -p
^Chttp-biographic-profile: internal error: Invalid object in processHeapClosureForDead(): 58
(GHC version 7.0.4 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
zsh: abort ./http-biographic-profile +RTS -hb -p
```
Empty heap profile generated is below:
```
JOB "biographic-profile +RTS -hb -p"
DATE "Thu May 17 17:12 2012"
SAMPLE_UNIT "seconds"
VALUE_UNIT "bytes"
BEGIN_SAMPLE 0.00
END_SAMPLE 0.00
```
I reproduce this behaviour in environments below:
- GHC-7.0.4 (x86_64_apple_darwin, OS X 10.6.8, distributed with haskell-platform 2011.3.0.0)
- GHC-7.4.1 (x86_64_apple_darwin, OS X 10.6.8, installed from tarball, sandboxed with virthualenv)
I think "-hb" show work even when program interrupted, because "-hy", "-hd", "-hr" and so on works in such a situation. Is this a intended behaviour?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Interrupted program cannot produce biographical heap profile","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I interrupt program running with \"+RTS -p -hb\" option, the program aborts with message below and I could only get empty heap profile.\r\n\r\nMinimal case is below:\r\n\r\n{{{\r\nmodule Main where\r\nmain :: IO ()\r\nmain = print $ sum [1..10000000000]\r\n}}}\r\n\r\nI compiled this code with \"-prof -rtsopts\" options, ran the program and then interrupt after several seconds.\r\n\r\n{{{\r\n$ ghc http-biographic-profile.hs -prof -rtsopts\r\n[1 of 1] Compiling Main ( http-biographic-profile.hs, http-biographic-profile.o )\r\nLinking biographic-profile ...\r\n$ ./http-biographic-profile +RTS -hb -p \r\n^Chttp-biographic-profile: internal error: Invalid object in processHeapClosureForDead(): 58\r\n (GHC version 7.0.4 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nzsh: abort ./http-biographic-profile +RTS -hb -p\r\n}}}\r\n\r\nEmpty heap profile generated is below:\r\n\r\n{{{\r\nJOB \"biographic-profile +RTS -hb -p\"\r\nDATE \"Thu May 17 17:12 2012\"\r\nSAMPLE_UNIT \"seconds\"\r\nVALUE_UNIT \"bytes\"\r\nBEGIN_SAMPLE 0.00\r\nEND_SAMPLE 0.00\r\n}}}\r\n\r\nI reproduce this behaviour in environments below:\r\n\r\n\r\n * GHC-7.0.4 (x86_64_apple_darwin, OS X 10.6.8, distributed with haskell-platform 2011.3.0.0)\r\n * GHC-7.4.1 (x86_64_apple_darwin, OS X 10.6.8, installed from tarball, sandboxed with virthualenv)\r\n\r\n\r\nI think \"-hb\" show work even when program interrupted, because \"-hy\", \"-hd\", \"-hr\" and so on works in such a situation. Is this a intended behaviour?","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6071Compiled program segfaults2019-07-07T18:52:19ZstevecheckowayCompiled program segfaultsWhen I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.
For some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size o...When I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.
For some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size of the stack, it will segfault on the 29th.
This program is fairly slow. Compiled with -O4, it took 3 minutes to segfault and used more than 20 GB of RAM.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"Compiled program segfaults","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.\r\n\r\nFor some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size of the stack, it will segfault on the 29th.\r\n\r\nThis program is fairly slow. Compiled with -O4, it took 3 minutes to segfault and used more than 20 GB of RAM.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6007ghci: Importing specific non-existent names from a module breaks later imports2019-07-07T18:52:37Zjoshghci: Importing specific non-existent names from a module breaks later importsAt the ghci prompt, attempting to import specific non-existent names from a module breaks any future import attempts, causing them to fail with the same error message that the original import failed with (in addition to any error message...At the ghci prompt, attempting to import specific non-existent names from a module breaks any future import attempts, causing them to fail with the same error message that the original import failed with (in addition to any error message they generate themselves). For example:
```
Prelude> import System.IO(foo)
<interactive>:1:18: Module `System.IO' does not export `foo'
Prelude> import Control.Monad.Error
<interactive>:1:18: Module `System.IO' does not export `foo'
```
Or compounding the problem:
```
Prelude> import System.IO(foo)
<interactive>:1:18: Module `System.IO' does not export `foo'
Prelude> import Control.Monad.Error(foo)
<interactive>:1:18: Module `System.IO' does not export `foo'
<interactive>:1:28:
Module `Control.Monad.Error' does not export `foo'
Prelude> import Control.Monad.Error
<interactive>:1:18: Module `System.IO' does not export `foo'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"ghci: Importing specific non-existent names from a module breaks later imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At the ghci prompt, attempting to import specific non-existent names from a module breaks any future import attempts, causing them to fail with the same error message that the original import failed with (in addition to any error message they generate themselves). For example:\r\n\r\n{{{\r\nPrelude> import System.IO(foo)\r\n\r\n<interactive>:1:18: Module `System.IO' does not export `foo'\r\nPrelude> import Control.Monad.Error\r\n\r\n<interactive>:1:18: Module `System.IO' does not export `foo'\r\n}}}\r\n\r\nOr compounding the problem:\r\n\r\n{{{\r\nPrelude> import System.IO(foo)\r\n\r\n<interactive>:1:18: Module `System.IO' does not export `foo'\r\nPrelude> import Control.Monad.Error(foo)\r\n\r\n<interactive>:1:18: Module `System.IO' does not export `foo'\r\n\r\n<interactive>:1:28:\r\n Module `Control.Monad.Error' does not export `foo'\r\nPrelude> import Control.Monad.Error\r\n\r\n<interactive>:1:18: Module `System.IO' does not export `foo'\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/6006hs_init(NULL, NULL) segfaults on latest snapshot2019-07-07T18:52:37ZEdward Z. Yanghs_init(NULL, NULL) segfaults on latest snapshotThis weeny program crashes:
```
int main(int argc, char** argv) {
hs_init(NULL,NULL);
}
```
Old versions of GHC accomodate null pointers fine, and there is an explicit check for this case inside the function. If this is intentional...This weeny program crashes:
```
int main(int argc, char** argv) {
hs_init(NULL,NULL);
}
```
Old versions of GHC accomodate null pointers fine, and there is an explicit check for this case inside the function. If this is intentional behavior change, it should be documented.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.5 |
| 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":"hs_init(NULL, NULL) segfaults on latest snapshot","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This weeny program crashes:\r\n\r\n{{{\r\nint main(int argc, char** argv) {\r\n hs_init(NULL,NULL);\r\n}\r\n}}}\r\n\r\nOld versions of GHC accomodate null pointers fine, and there is an explicit check for this case inside the function. If this is intentional behavior change, it should be documented.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5969Runtime crashes on parallel execution, GHC 7.0.4-7.4.12019-07-07T18:52:48ZPeterisPRuntime crashes on parallel execution, GHC 7.0.4-7.4.1Code gets runtime crashes if executed on multiple parallel threads with `Control.Monad.Parallel.mapM` - if the whole data is passed as one chunk to the `mapM`, then crashes are avoided.
The crashes are repeatable (same code with the sam...Code gets runtime crashes if executed on multiple parallel threads with `Control.Monad.Parallel.mapM` - if the whole data is passed as one chunk to the `mapM`, then crashes are avoided.
The crashes are repeatable (same code with the same data crashes 90% of time), but with different crash messages and place/time of crash.
For example:
```
"LNB_transform_source: internal error: stg_ap_p_ret
(GHC version 7.0.4 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6"
Another: "Bus error: 10"
Another, after successfully finishing execution
"LNB_transform_source(22223,0x7fff7e200960) malloc: *** error for object 0x2c: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6"
Another: "Segmentation fault: 11"
```
I cannot isolate a minimalistic test case easily; the program is quite tricky and didn't crash when was simpler; however, the problems appeared around the same time as when xml parsing was switched from Text.XML.HXT.Core to Text.XML.Expat.SAX library, but there was a load of other changes at the same time.
very rough code logic:
```
Control.Monad.Parallel.mapM processfiles [[filenames]]
Parallel.processfiles = do
outsideapphandles <- runInteractiveCommand "outsideapp"
mapM (processfile handles) [filenames]
processfile = do
file <- readfile filename
tokens <- SAX.parse file
outputtokens <- map (processtoken outsideapphandles) tokens
writefile outputtokens
processtoken = unsafeperformIO $ do
hPutStrLn inputhandle token
return hgetLine outputhandle
```7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5946getAnyProcessStatus signals an exception2019-07-07T18:52:53ZtocgetAnyProcessStatus signals an exceptionSteps to reproduce:
```
$ ghci-7.0.4
Prelude> import System.Posix
Prelude System.Posix> getAnyProcessStatus False False
```
Expected result:
```
Nothing
```
Actual result:
```
*** Exception: getGroupProcessStatus: does not exist (No...Steps to reproduce:
```
$ ghci-7.0.4
Prelude> import System.Posix
Prelude System.Posix> getAnyProcessStatus False False
```
Expected result:
```
Nothing
```
Actual result:
```
*** Exception: getGroupProcessStatus: does not exist (No child processes)
```
Tested on 6.12.1 and 7.0.4, Mac OS X 10.7 and Ubuntu 10.04.4 LTS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getAnyProcessStatus signals an exception","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n{{{\r\n$ ghci-7.0.4\r\nPrelude> import System.Posix\r\nPrelude System.Posix> getAnyProcessStatus False False\r\n}}}\r\n\r\nExpected result:\r\n{{{\r\nNothing\r\n}}}\r\n\r\nActual result:\r\n{{{\r\n*** Exception: getGroupProcessStatus: does not exist (No child processes)\r\n}}}\r\n\r\nTested on 6.12.1 and 7.0.4, Mac OS X 10.7 and Ubuntu 10.04.4 LTS.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5944Bad hpc hash function2019-07-07T18:52:54Zlennart@augustsson.netBad hpc hash functionIn the hpc module Trace.Hpc.Util there is the following code:
```
instance (HpcHash a,HpcHash b) => HpcHash (a,b) where
toHash (a,b) = toHash a * 33 `hxor` toHash b
```
This is bad and I can only presume that what was actually intend...In the hpc module Trace.Hpc.Util there is the following code:
```
instance (HpcHash a,HpcHash b) => HpcHash (a,b) where
toHash (a,b) = toHash a * 33 `hxor` toHash b
```
This is bad and I can only presume that what was actually intended was
```
instance (HpcHash a,HpcHash b) => HpcHash (a,b) where
toHash (a,b) = (toHash a * 33) `hxor` toHash b
```
Otherwise a hash of 0 for a will result in a total hash of 0.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bad hpc hash function","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the hpc module Trace.Hpc.Util there is the following code:\r\n\r\n{{{\r\ninstance (HpcHash a,HpcHash b) => HpcHash (a,b) where\r\n toHash (a,b) = toHash a * 33 `hxor` toHash b\r\n}}}\r\n\r\nThis is bad and I can only presume that what was actually intended was\r\n\r\n{{{\r\ninstance (HpcHash a,HpcHash b) => HpcHash (a,b) where\r\n toHash (a,b) = (toHash a * 33) `hxor` toHash b\r\n}}}\r\n\r\nOtherwise a hash of 0 for a will result in a total hash of 0.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5943Code without MVar: "thread blocked indefinitely in an MVar operation"2019-07-07T18:52:54ZcobbCode without MVar: "thread blocked indefinitely in an MVar operation"The attached code produces the above message when compiled with optimisations on - even -O1 is enough. The same happens on both 32 and 64-bit architectures.
<details><summary>Trac metadata</summary>
| Trac field | Value ...The attached code produces the above message when compiled with optimisations on - even -O1 is enough. The same happens on both 32 and 64-bit architectures.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"Code without MVar: \"thread blocked indefinitely in an MVar operation\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached code produces the above message when compiled with optimisations on - even -O1 is enough. The same happens on both 32 and 64-bit architectures.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5932closure_type_names in Printer.c has BLACKHOLE and BLOCKING_QUEUE swapped2019-07-07T18:52:57ZJoachim Breitnermail@joachim-breitner.declosure_type_names in Printer.c has BLACKHOLE and BLOCKING_QUEUE swappedThe attached patch fixes this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug...The attached patch fixes this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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":"closure_type_names in Printer.c has BLACKHOLE and BLOCKING_QUEUE swapped","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached patch fixes this.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5896Three documentations inaccuracies related to concurrency.2019-07-07T18:53:05ZMikolaj KonarskiThree documentations inaccuracies related to concurrency.1.
The help info below is wrong. The default is the actual number of cores, or something close.
```
~/waste/threadscope-sparkgraph-demo75$ ./parlist +RTS -N2 -lg -s -asdfasdf
parlist: unknown RTS option: -asdfasdf
[...]
parlist: -N<n...1.
The help info below is wrong. The default is the actual number of cores, or something close.
```
~/waste/threadscope-sparkgraph-demo75$ ./parlist +RTS -N2 -lg -s -asdfasdf
parlist: unknown RTS option: -asdfasdf
[...]
parlist: -N<n> Use <n> processors (default: 1)
```
2.
Here:
http://www.haskell.org/ghc/docs/latest/html/users_guide/using-smp.html
the first sentence of the following is wrong and could be just removed.
```
There is no means (currently) by which this value may vary after the program has started.
The current value of the -N option is available to the Haskell program via GHC.Conc.getNumCapabilities, and it may be changed while the program is running by calling GHC.Conc.setNumCapabilities. Note: in the current implementation, the -N value may only be increased, not decreased, by calling GHC.Conc.setNumCapabilities.
```
3.
Neither here
http://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.html
nor on first page of the docs it refers to:
http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.5.0.0/Control-Concurrent.html
is there any hint about the possibility and advantages of using "-threaded" and "+RTS -N". It may be misleading to the users that specifically seek an information about any extra flags they need to start using multiple cores or non-blocking FFI calls.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Three documentations inaccuracies related to concurrency.","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1.\r\n\r\nThe help info below is wrong. The default is the actual number of cores, or something close.\r\n\r\n{{{\r\n~/waste/threadscope-sparkgraph-demo75$ ./parlist +RTS -N2 -lg -s -asdfasdf\r\nparlist: unknown RTS option: -asdfasdf\r\n[...]\r\nparlist: -N<n> Use <n> processors (default: 1)\r\n}}}\r\n\r\n2.\r\n\r\nHere:\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/users_guide/using-smp.html\r\n\r\nthe first sentence of the following is wrong and could be just removed.\r\n\r\n\r\n{{{\r\nThere is no means (currently) by which this value may vary after the program has started.\r\n\r\nThe current value of the -N option is available to the Haskell program via GHC.Conc.getNumCapabilities, and it may be changed while the program is running by calling GHC.Conc.setNumCapabilities. Note: in the current implementation, the -N value may only be increased, not decreased, by calling GHC.Conc.setNumCapabilities.\r\n}}}\r\n\r\n3.\r\n\r\nNeither here\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/users_guide/using-concurrent.html\r\n\r\nnor on first page of the docs it refers to:\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/libraries/base-4.5.0.0/Control-Concurrent.html\r\n\r\nis there any hint about the possibility and advantages of using \"-threaded\" and \"+RTS -N\". It may be misleading to the users that specifically seek an information about any extra flags they need to start using multiple cores or non-blocking FFI calls.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5891"createDirectory: already exists" error with parallel build2019-07-07T18:53:06Ztakano-akio"createDirectory: already exists" error with parallel buildWhen I invoke multiple instances of GHC in parallel, I sometimes get an error: \<path\>: createDirectory: already exists (File exists). The attached script demonstrates this.
<details><summary>Trac metadata</summary>
| Trac field ...When I invoke multiple instances of GHC in parallel, I sometimes get an error: \<path\>: createDirectory: already exists (File exists). The attached script demonstrates this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"\"createDirectory: already exists\" error with parallel build","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I invoke multiple instances of GHC in parallel, I sometimes get an error: <path>: createDirectory: already exists (File exists). The attached script demonstrates this.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5878main-is is too conservative2019-07-07T18:53:09ZSimon Peyton Jonesmain-is is too conservativeConrad Parker writes: We have a project with around 200 Haskell source files, and around 20
executables which import these (as well as importing third-party
libraries). We first build all the non-main files using a makefile
generated wit...Conrad Parker writes: We have a project with around 200 Haskell source files, and around 20
executables which import these (as well as importing third-party
libraries). We first build all the non-main files using a makefile
generated with `ghc -M`. We then build the executables using a separate
invocation of "`ghc --make --main-is foo.hs`", for each foo.hs. This
worked fine with ghc-7.2.1; each final "`ghc --make`" would simply link
the pre-built object files -- but with ghc-7.4.1 all these files are
recompiled for each target executable. As a result our full build
takes around **10-20x longer with ghc-7.4.1 than ghc-7.2.1**.
Looking at `compiler/iface/FlagChecker.hs`, it seems that the `--main-is`
flag is used as an input to the recompilation checker. It would make
sense that `--main-is` should force recompilation of the particular file
that exports '`main`', but it also forces recompilation of its
dependencies. Is this a bug or is there a good reason to recompile
everything?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"main-is is too conservative","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Conrad Parker writes: We have a project with around 200 Haskell source files, and around 20\r\nexecutables which import these (as well as importing third-party\r\nlibraries). We first build all the non-main files using a makefile\r\ngenerated with `ghc -M`. We then build the executables using a separate\r\ninvocation of \"`ghc --make --main-is foo.hs`\", for each foo.hs. This\r\nworked fine with ghc-7.2.1; each final \"`ghc --make`\" would simply link\r\nthe pre-built object files -- but with ghc-7.4.1 all these files are\r\nrecompiled for each target executable. As a result our full build\r\ntakes around '''10-20x longer with ghc-7.4.1 than ghc-7.2.1'''.\r\n\r\nLooking at `compiler/iface/FlagChecker.hs`, it seems that the `--main-is`\r\nflag is used as an input to the recompilation checker. It would make\r\nsense that `--main-is` should force recompilation of the particular file\r\nthat exports '`main`', but it also forces recompilation of its\r\ndependencies. Is this a bug or is there a good reason to recompile\r\neverything?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5874Document autoconf dependency in README2019-07-07T18:53:11ZJamesFisherDocument autoconf dependency in READMEThe `boot` script calls `autoreconf` on line 204. If not present this gives the error message
```
[...]
Booting .
Can't exec "autoreconf": No such file or directory at boot line 204, <PKGS> line 2.
Running autoreconf failed with exitcod...The `boot` script calls `autoreconf` on line 204. If not present this gives the error message
```
[...]
Booting .
Can't exec "autoreconf": No such file or directory at boot line 204, <PKGS> line 2.
Running autoreconf failed with exitcode -1 at boot line 204, <PKGS> line 2.
```
For those following the `README` to build GHC for the first time this is unfriendly. I had to Google to find that I had to install the `autoconf` package (on Ubuntu).
The dependency on `autoconf` should be documented in `README`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Document autoconf dependency in README","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The {{{boot}}} script calls {{{autoreconf}}} on line 204. If not present this gives the error message\r\n\r\n{{{\r\n[...]\r\nBooting .\r\nCan't exec \"autoreconf\": No such file or directory at boot line 204, <PKGS> line 2.\r\nRunning autoreconf failed with exitcode -1 at boot line 204, <PKGS> line 2.\r\n}}}\r\n\r\nFor those following the {{{README}}} to build GHC for the first time this is unfriendly. I had to Google to find that I had to install the {{{autoconf}}} package (on Ubuntu).\r\n\r\nThe dependency on {{{autoconf}}} should be documented in {{{README}}}.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5870writeChan is not 100% exception-safe2019-07-07T18:53:11ZjoeyadamswriteChan is not 100% exception-safeControl.Concurrent.Chan.writeChan is currently implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
modifyMVar_ writeVar $ \old_hole -> do
putMVar old_hole (C...Control.Concurrent.Chan.writeChan is currently implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
modifyMVar_ writeVar $ \old_hole -> do
putMVar old_hole (ChItem val new_hole)
return new_hole
```
The problem is that modifyMVar_ restores the exception mask when it calls the callback. If an asynchronous exception is delivered immediately after the putMVar, the Chan's write end will be set to a filled hole, violating a key invariant.
I think it should be implemented like this:
```
writeChan :: Chan a -> a -> IO ()
writeChan (Chan _ writeVar) val = do
new_hole <- newEmptyMVar
mask_ $ do
old_hole <- takeMVar writeVar -- (1)
putMVar old_hole (ChItem val new_hole) -- (2)
putMVar writeVar new_hole -- (3)
```
This looks a bit naïve, but it should be atomic, at least in theory:
- (1) is interruptible. However, if it is interrupted, the MVar will remain intact.
- (2) is not interruptible, because old_hole is guaranteed to be empty. No other thread can fill it because we have taken exclusive access to writeVar.
- (3) is not interruptible, because we have taken exclusive access to writeVar.
This implementation has the added benefit of removing an exception handler, which should make it slightly faster.
readChan is okay, though:
```
readChan :: Chan a -> IO a
readChan (Chan readVar _) = do
modifyMVar readVar $ \read_end -> do
(ChItem val new_read_end) <- readMVar read_end
return (new_read_end, val)
```
If an exception is received immediately after the readMVar, then the read cursor will not be advanced, and the next call to readChan will simply read from that position again. Unfortunately, we can't get rid of the exception handler like we did with writeChan, because `readMVar read_end` is interruptible.
The attached patch changes the implementation of writeChan to the one shown above, and adds a comment to the definition of Chan about the write end's empty-hole invariant. I believe all of the Chan operations preserve this invariant, even the deprecated unGetChan and isEmptyChan.
I have not been able to create a test case where writeChan is interrupted between filling the hole and updating the write cursor. Perhaps it doesn't actually happen in practice, or perhaps it is extremely rare. But by my understanding of the semantics:
```
mask $ \restore -> do
thing1
restore $ putMVar ...
thing2
```
It is possible for an exception to arrive after the putMVar and before thing2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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":"writeChan is not 100% exception-safe","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Control.Concurrent.Chan.writeChan is currently implemented like this:\r\n\r\n{{{\r\nwriteChan :: Chan a -> a -> IO ()\r\nwriteChan (Chan _ writeVar) val = do\r\n new_hole <- newEmptyMVar\r\n modifyMVar_ writeVar $ \\old_hole -> do\r\n putMVar old_hole (ChItem val new_hole)\r\n return new_hole\r\n}}}\r\n\r\nThe problem is that modifyMVar_ restores the exception mask when it calls the callback. If an asynchronous exception is delivered immediately after the putMVar, the Chan's write end will be set to a filled hole, violating a key invariant.\r\n\r\nI think it should be implemented like this:\r\n\r\n{{{\r\nwriteChan :: Chan a -> a -> IO ()\r\nwriteChan (Chan _ writeVar) val = do\r\n new_hole <- newEmptyMVar\r\n mask_ $ do\r\n old_hole <- takeMVar writeVar -- (1)\r\n putMVar old_hole (ChItem val new_hole) -- (2)\r\n putMVar writeVar new_hole -- (3)\r\n}}}\r\n\r\nThis looks a bit naïve, but it should be atomic, at least in theory:\r\n\r\n * (1) is interruptible. However, if it is interrupted, the MVar will remain intact.\r\n\r\n * (2) is not interruptible, because old_hole is guaranteed to be empty. No other thread can fill it because we have taken exclusive access to writeVar.\r\n\r\n * (3) is not interruptible, because we have taken exclusive access to writeVar.\r\n\r\nThis implementation has the added benefit of removing an exception handler, which should make it slightly faster.\r\n\r\nreadChan is okay, though:\r\n\r\n{{{\r\nreadChan :: Chan a -> IO a\r\nreadChan (Chan readVar _) = do\r\n modifyMVar readVar $ \\read_end -> do\r\n (ChItem val new_read_end) <- readMVar read_end\r\n return (new_read_end, val)\r\n}}}\r\n\r\nIf an exception is received immediately after the readMVar, then the read cursor will not be advanced, and the next call to readChan will simply read from that position again. Unfortunately, we can't get rid of the exception handler like we did with writeChan, because {{{readMVar read_end}}} is interruptible.\r\n\r\nThe attached patch changes the implementation of writeChan to the one shown above, and adds a comment to the definition of Chan about the write end's empty-hole invariant. I believe all of the Chan operations preserve this invariant, even the deprecated unGetChan and isEmptyChan.\r\n\r\nI have not been able to create a test case where writeChan is interrupted between filling the hole and updating the write cursor. Perhaps it doesn't actually happen in practice, or perhaps it is extremely rare. But by my understanding of the semantics:\r\n\r\n{{{\r\nmask $ \\restore -> do\r\n thing1\r\n restore $ putMVar ...\r\n thing2\r\n}}}\r\n\r\nIt is possible for an exception to arrive after the putMVar and before thing2.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5866Interrupting interleaved STM and resuming it produces segfault2019-07-07T18:53:13ZjoeyadamsInterrupting interleaved STM and resuming it produces segfaultThe following program produces a segfault:
```
import Control.Concurrent.STM
import Control.Exception
import System.IO.Unsafe
import System.Timeout
main :: IO ()
main = do
x <- unsafeInterleaveIO $ atomically retry
_ <- timeout...The following program produces a segfault:
```
import Control.Concurrent.STM
import Control.Exception
import System.IO.Unsafe
import System.Timeout
main :: IO ()
main = do
x <- unsafeInterleaveIO $ atomically retry
_ <- timeout 1000000 $ evaluate x
evaluate x
```
When a thread is interrupted while evaluating interleaved IO, and that IO is blocked on an STM transaction, resuming the suspended computation produces a segfault.
This segfault happens with GHC 7.0.3, 7.2.2, and 7.4.1, on both Windows 32-bit and Linux 64-bit, with and without -threaded.
Compiling with -debug on 7.5.20120211, I get an assertion failure in rts/STM.c, line 1525:
```
ASSERT (trec != NO_TREC);
```
In general, pure computations are not always suspended by asynchronous exceptions:
```
import Control.Concurrent
import System.IO.Unsafe
import System.Timeout
main :: IO ()
main = do
-- Resuming interleaved takeMVar works correctly
mv <- newEmptyMVar
_ <- forkIO $ threadDelay 2000000 >> putMVar mv "Hello"
s <- unsafeInterleaveIO $ takeMVar mv
_ <- timeout 1000000 $ putStrLn s
putStrLn s
-- But resuming getLine repeats the asynchronous exception, contrary to the
-- documentation of 'throwTo'
s <- unsafeInterleaveIO getLine
_ <- timeout 1000000 $ putStrLn s
putStrLn s
```
Note issue #5859 when testing: unsafeInterleaveIO being INLINE causes computations to be duplicated when shared among threads. The examples above dodge this issue by keeping the work in the current thread.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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":"Interrupting interleaved STM and resuming it produces segfault","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program produces a segfault:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Exception\r\nimport System.IO.Unsafe\r\nimport System.Timeout\r\n\r\nmain :: IO ()\r\nmain = do\r\n x <- unsafeInterleaveIO $ atomically retry\r\n _ <- timeout 1000000 $ evaluate x\r\n evaluate x\r\n}}}\r\n\r\nWhen a thread is interrupted while evaluating interleaved IO, and that IO is blocked on an STM transaction, resuming the suspended computation produces a segfault.\r\n\r\nThis segfault happens with GHC 7.0.3, 7.2.2, and 7.4.1, on both Windows 32-bit and Linux 64-bit, with and without -threaded. \r\n\r\nCompiling with -debug on 7.5.20120211, I get an assertion failure in rts/STM.c, line 1525:\r\n\r\n{{{\r\nASSERT (trec != NO_TREC);\r\n}}}\r\n\r\nIn general, pure computations are not always suspended by asynchronous exceptions:\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport System.IO.Unsafe\r\nimport System.Timeout\r\n\r\nmain :: IO ()\r\nmain = do\r\n -- Resuming interleaved takeMVar works correctly\r\n mv <- newEmptyMVar\r\n _ <- forkIO $ threadDelay 2000000 >> putMVar mv \"Hello\"\r\n s <- unsafeInterleaveIO $ takeMVar mv\r\n _ <- timeout 1000000 $ putStrLn s\r\n putStrLn s\r\n\r\n -- But resuming getLine repeats the asynchronous exception, contrary to the\r\n -- documentation of 'throwTo'\r\n s <- unsafeInterleaveIO getLine\r\n _ <- timeout 1000000 $ putStrLn s\r\n putStrLn s\r\n}}}\r\n\r\nNote issue #5859 when testing: unsafeInterleaveIO being INLINE causes computations to be duplicated when shared among threads. The examples above dodge this issue by keeping the work in the current thread.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5851RTS Crashes on Exit with double free2019-07-07T18:53:18ZargiopewebRTS Crashes on Exit with double freeOn compiling with
```
ghc -threaded -with-rtsopts="-N2 -A4m -H128m -G4"
```
or
```
ghc -threaded -with-rtsopts="-N2 -H128m -G4"
```
RTS crashes on exit (normal or sigINT) with glibc "free(): invalid pointer" and "double free or corr...On compiling with
```
ghc -threaded -with-rtsopts="-N2 -A4m -H128m -G4"
```
or
```
ghc -threaded -with-rtsopts="-N2 -H128m -G4"
```
RTS crashes on exit (normal or sigINT) with glibc "free(): invalid pointer" and "double free or corruption (out)" errors, respectively.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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 Crashes on Exit with double free","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["free","glibc","pointer","rts"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On compiling with \r\n{{{\r\nghc -threaded -with-rtsopts=\"-N2 -A4m -H128m -G4\"\r\n}}}\r\n or \r\n{{{\r\nghc -threaded -with-rtsopts=\"-N2 -H128m -G4\"\r\n}}}\r\nRTS crashes on exit (normal or sigINT) with glibc \"free(): invalid pointer\" and \"double free or corruption (out)\" errors, respectively.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5838integer overflow in rts/RtsUtils:heapOverflow()2019-07-07T18:53:23ZHerbert Valerio Riedelhvr@gnu.orginteger overflow in rts/RtsUtils:heapOverflow()When failing with a heap exhaustion, the RTS truncates the **reported** *current maximum heap size* modulo 2\^32, e.g.
```
$ ghc +RTS -M4G -RTS -e 'sum [1..]'
Heap exhausted;
Current maximum heap size is 0 bytes (0 MB);
use `+RTS -M<siz...When failing with a heap exhaustion, the RTS truncates the **reported** *current maximum heap size* modulo 2\^32, e.g.
```
$ ghc +RTS -M4G -RTS -e 'sum [1..]'
Heap exhausted;
Current maximum heap size is 0 bytes (0 MB);
use `+RTS -M<size>' to increase it.
```
This is most probably due to `OutOfHeapHook()` already being called with the truncated value from `heapOverflow()`:
```c
void
heapOverflow(void)
{
if (!heap_overflow)
{
/* don't fflush(stdout); WORKAROUND bug in Linux glibc */
OutOfHeapHook(0/*unknown request size*/,
RtsFlags.GcFlags.maxHeapSize * BLOCK_SIZE);
heap_overflow = rtsTrue;
}
}
```
which multiplies `RtsFlags.GcFlags.maxHeapSize` and `BLOCK_SIZE` whose type are 32-bit `unsigned int`s, causing the result to be wrapped again into an `unsigned int`, whereas the result should be upcasted to a `long unsigned int` (which at least on 64bit archs would be equivalent to a C99 `uint64_t`)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.2 |
| 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":"integer overflow in rts/RtsUtils:heapOverflow()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When failing with a heap exhaustion, the RTS truncates the '''reported''' ''current maximum heap size'' modulo 2^32, e.g.\r\n\r\n{{{\r\n$ ghc +RTS -M4G -RTS -e 'sum [1..]'\r\nHeap exhausted;\r\nCurrent maximum heap size is 0 bytes (0 MB);\r\nuse `+RTS -M<size>' to increase it.\r\n}}}\r\n\r\nThis is most probably due to `OutOfHeapHook()` already being called with the truncated value from `heapOverflow()`:\r\n\r\n{{{\r\n#!c\r\nvoid\r\nheapOverflow(void)\r\n{\r\n if (!heap_overflow)\r\n {\r\n /* don't fflush(stdout); WORKAROUND bug in Linux glibc */\r\n OutOfHeapHook(0/*unknown request size*/,\r\n RtsFlags.GcFlags.maxHeapSize * BLOCK_SIZE);\r\n\r\n heap_overflow = rtsTrue;\r\n }\r\n}\r\n}}}\r\n\r\nwhich multiplies `RtsFlags.GcFlags.maxHeapSize` and `BLOCK_SIZE` whose type are 32-bit `unsigned int`s, causing the result to be wrapped again into an `unsigned int`, whereas the result should be upcasted to a `long unsigned int` (which at least on 64bit archs would be equivalent to a C99 `uint64_t`)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5836GHCi silently fails to import non-existing modules2019-07-07T18:53:23ZHerbert Valerio Riedelhvr@gnu.orgGHCi silently fails to import non-existing modulesE.g.:
```
$ ghci
GHCi, version 7.4.0.20120126: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude>...E.g.:
```
$ ghci
GHCi, version 7.4.0.20120126: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Non.Existing.Module
Prelude> :show imports
import Prelude -- implicit
import Non.Existing.Module
Prelude> :m
Prelude> :show imports
import Prelude -- implicit
Prelude>
```
whereas in GHC 7.2.2, it behaved like:
```
GHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> import Non.Existing.Module
<no location info>:
Could not find module `Non.Existing.Module'
Use -v to see a list of the files searched for.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1-rc2 |
| 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":"GHCi silently fails to import non-existing modules","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"E.g.:\r\n{{{\r\n$ ghci\r\nGHCi, version 7.4.0.20120126: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nPrelude> import Non.Existing.Module\r\nPrelude> :show imports\r\nimport Prelude -- implicit\r\nimport Non.Existing.Module\r\nPrelude> :m\r\nPrelude> :show imports\r\nimport Prelude -- implicit\r\nPrelude> \r\n}}}\r\n\r\nwhereas in GHC 7.2.2, it behaved like:\r\n{{{\r\nGHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> import Non.Existing.Module\r\n\r\n<no location info>:\r\n Could not find module `Non.Existing.Module'\r\n Use -v to see a list of the files searched for.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlow