GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:56:30Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5187missing deRefTSO in scheduleHandleThreadFinished2019-07-07T18:56:30ZSimon Marlowmissing deRefTSO in scheduleHandleThreadFinishedDuncan Coutts reported this one. ThreadScope was crashing, we think because in `scheduleHandleThreadFinished` there ought to be a call to `deRefTSO` before
```
ASSERT(task->incall->tso == t);
```
(the value of `task->incall->tso is ...Duncan Coutts reported this one. ThreadScope was crashing, we think because in `scheduleHandleThreadFinished` there ought to be a call to `deRefTSO` before
```
ASSERT(task->incall->tso == t);
```
(the value of `task->incall->tso is used for real a bit further down).
This only applies to the 7.0 branch, `deRefTSO\` has gone in 7.2 and later.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dcoutts |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"missing deRefTSO in scheduleHandleThreadFinished","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.0.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dcoutts"],"type":"Bug","description":"Duncan Coutts reported this one. ThreadScope was crashing, we think because in `scheduleHandleThreadFinished` there ought to be a call to `deRefTSO` before \r\n\r\n{{{\r\n\t ASSERT(task->incall->tso == t);\r\n}}}\r\n\r\n(the value of `task->incall->tso is used for real a bit further down).\r\n\r\nThis only applies to the 7.0 branch, `deRefTSO` has gone in 7.2 and later.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/5149NaNs produced by sorting mutable Double vectors2019-07-07T18:56:41Zdaniel.is.fischerNaNs produced by sorting mutable Double vectorsUnder some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either,...Under some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either, and for the attached programme (requires vector and vector-algorithms), the only difference in the assembly produced by 7.0.2 and 7.0.3 (apart from different unique names) is the presence of some FPU-freeings in 7.0.3's which 7.0.2 didn't produce, likely caused by the fix to #4914.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.3 |
| 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":"NaNs produced by sorting mutable Double vectors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Under some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either, and for the attached programme (requires vector and vector-algorithms), the only difference in the assembly produced by 7.0.2 and 7.0.3 (apart from different unique names) is the presence of some FPU-freeings in 7.0.3's which 7.0.2 didn't produce, likely caused by the fix to #4914.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4https://gitlab.haskell.org/ghc/ghc/-/issues/5004loading stripped libHsghc-7.0.2.a fails2019-07-07T18:57:22Zpbrisbinloading stripped libHsghc-7.0.2.a failsArch linux's ghc package was upgraded to 7.0.2 this weekend. I unregistered all cabal packages, removed \~/.cabal/packages/\*/\* and \~/.ghc in an effort to start fresh.
I successfully installed quite a few packages via cabal install.
...Arch linux's ghc package was upgraded to 7.0.2 this weekend. I unregistered all cabal packages, removed \~/.cabal/packages/\*/\* and \~/.ghc in an effort to start fresh.
I successfully installed quite a few packages via cabal install.
You can find my current `ghc-pkg list` [here](http://pbrisbin.com/static/fileshare/ghc_list.txt).
At `cabal install yesod`, I get the following:
```
...
Loading package MonadCatchIO-mtl-0.3.0.2 ... linking ... done.
Loading package Cabal-1.10.1.0 ... linking ... done.
Loading package ghc-binary-0.5.0.2 ... linking ... done.
Loading package bin-package-db-0.0.0.0 ... linking ... done.
Loading package hpc-0.5.0.6 ... linking ... done.
Loading package ghc-7.0.2 ... ghc: This ELF file contains no symtab
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.2 for x86_64-unknown-linux):
loadArchive "/usr/lib/ghc-7.0.2/ghc-7.0.2/libHSghc-7.0.2.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
yesod-0.7.1 failed during the building phase. The exception was:
ExitFailure 1
```
I'm reporting here because I was specifically asked to by ghc (I almost always assume these things are my fault), please let me know what additional info you would like in this report.
Thanks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.2 |
| Type | Bug |
| TypeOfFailure | CompileTimeCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"yesod-0.7.1 fails to build on ghc 7.0.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Arch linux's ghc package was upgraded to 7.0.2 this weekend. I unregistered all cabal packages, removed ~/.cabal/packages/*/* and ~/.ghc in an effort to start fresh.\r\n\r\nI successfully installed quite a few packages via cabal install.\r\n\r\nYou can find my current `ghc-pkg list` [http://pbrisbin.com/static/fileshare/ghc_list.txt here].\r\n\r\nAt `cabal install yesod`, I get the following:\r\n\r\n{{{\r\n...\r\nLoading package MonadCatchIO-mtl-0.3.0.2 ... linking ... done.\r\nLoading package Cabal-1.10.1.0 ... linking ... done.\r\nLoading package ghc-binary-0.5.0.2 ... linking ... done.\r\nLoading package bin-package-db-0.0.0.0 ... linking ... done.\r\nLoading package hpc-0.5.0.6 ... linking ... done.\r\nLoading package ghc-7.0.2 ... ghc: This ELF file contains no symtab\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.0.2 for x86_64-unknown-linux):\r\n loadArchive \"/usr/lib/ghc-7.0.2/ghc-7.0.2/libHSghc-7.0.2.a\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Error: some packages failed to install:\r\nyesod-0.7.1 failed during the building phase. The exception was:\r\nExitFailure 1\r\n}}}\r\n\r\nI'm reporting here because I was specifically asked to by ghc (I almost always assume these things are my fault), please let me know what additional info you would like in this report.\r\n\r\nThanks.\r\n","type_of_failure":"CompileTimeCrash","blocking":[]} -->7.0.4duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/5226<<loop>> with -threaded -feager-blackholing, but only sometimes2019-07-07T18:56:21Zdreixel<<loop>> with -threaded -feager-blackholing, but only sometimesWhile benchmarking the performance of GHC's SMP parallelism, I ran into an issue where (rarely) a test would fail with `<<loop>>`. I tried hard to reduce this to a single file, which I am attaching to this report.
To reproduce, compile ...While benchmarking the performance of GHC's SMP parallelism, I ran into an issue where (rarely) a test would fail with `<<loop>>`. I tried hard to reduce this to a single file, which I am attaching to this report.
To reproduce, compile the program with `--make -threaded -feager-blackholing -rtsopts -O1` and run multiple times with `-Nm` with `m>=2`. In my case, using `N8` (on a machine with 8 cores), I once got the error after 35 tries, but sometimes it takes thousands of attempts. I'm also attaching a bash script to compile and run the test repeatedly.
Tested with current HEAD, built on a Intel Xeon E5320, "perf" settings without dynamic linking. But I think I also encountered this behavior in GHC 7.0.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"<<loop>> with -threaded -feager-blackholing, but only sometimes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While benchmarking the performance of GHC's SMP parallelism, I ran into an issue where (rarely) a test would fail with `<<loop>>`. I tried hard to reduce this to a single file, which I am attaching to this report.\r\n\r\nTo reproduce, compile the program with `--make -threaded -feager-blackholing -rtsopts -O1` and run multiple times with `-Nm` with `m>=2`. In my case, using `N8` (on a machine with 8 cores), I once got the error after 35 tries, but sometimes it takes thousands of attempts. I'm also attaching a bash script to compile and run the test repeatedly.\r\n\r\nTested with current HEAD, built on a Intel Xeon E5320, \"perf\" settings without dynamic linking. But I think I also encountered this behavior in GHC 7.0.3.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5127internal error heapCensus unknown object with +RTS -N -hT2019-07-07T18:56:47ZClaudiusMaximusinternal error heapCensus unknown object with +RTS -N -hT```
$ ghc -O3 -Wall --make -threaded -rtsopts -fspec-constr-count=50 autotune.hs
...
$ ./autotune +RTS -N -hT -RTS
...
autotune: internal error: heapCensus, unknown object: -538405951
(GHC version 7.0.3 for x86_64_unknown_linux)
...```
$ ghc -O3 -Wall --make -threaded -rtsopts -fspec-constr-count=50 autotune.hs
...
$ ./autotune +RTS -N -hT -RTS
...
autotune: internal error: heapCensus, unknown object: -538405951
(GHC version 7.0.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The unknown object number varies between program runs, and I got a segmentation fault too in one test.
I didn't manage to provoke a crash with each of -N or -hT alone, but the combination seems problematic.
I compiled ghc-7.0.3 from source with INTEGER_LIBRARY=integer-simple (so I can use hmpfr); my code uses hmpfr, parallel, ad, Vec, and possibly some other things from hackage too - I can try to make a simple test case at some point, or attach the code as-is if it would be useful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | claudiusmaximus@goto10.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error heapCensus unknown object with +RTS -N -hT","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["claudiusmaximus@goto10.org"],"type":"Bug","description":"{{{\r\n$ ghc -O3 -Wall --make -threaded -rtsopts -fspec-constr-count=50 autotune.hs\r\n...\r\n$ ./autotune +RTS -N -hT -RTS\r\n...\r\nautotune: internal error: heapCensus, unknown object: -538405951\r\n (GHC version 7.0.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe unknown object number varies between program runs, and I got a segmentation fault too in one test.\r\n\r\nI didn't manage to provoke a crash with each of -N or -hT alone, but the combination seems problematic.\r\n\r\nI compiled ghc-7.0.3 from source with INTEGER_LIBRARY=integer-simple (so I can use hmpfr); my code uses hmpfr, parallel, ad, Vec, and possibly some other things from hackage too - I can try to make a simple test case at some point, or attach the code as-is if it would be useful.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5086internal error: update_fwd: unknown/strange object -12060043762019-07-07T18:56:57Zdanwinternal error: update_fwd: unknown/strange object -1206004376When I compile my parallel program with the following command line:
ghc -O2 --make -threaded Main.hs
Then run the program with the following command:
1. /keno +RTS -N -M8G
The program crashes with the following error:
keno: internal ...When I compile my parallel program with the following command line:
ghc -O2 --make -threaded Main.hs
Then run the program with the following command:
1. /keno +RTS -N -M8G
The program crashes with the following error:
keno: internal error: update_fwd: unknown/strange object -1206004376
(GHC version 6.12.3 for x86_64_unknown_linux)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
If the heap were too small then I would expect the runtime system to tell me that the heap is too small rather than blow up like this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| 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":"internal error: update_fwd: unknown/strange object -1206004376","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I compile my parallel program with the following command line:\r\n\r\nghc -O2 --make -threaded Main.hs\r\n\r\nThen run the program with the following command:\r\n\r\n./keno +RTS -N -M8G\r\n\r\nThe program crashes with the following error:\r\nkeno: internal error: update_fwd: unknown/strange object -1206004376 \r\n (GHC version 6.12.3 for x86_64_unknown_linux) \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nIf the heap were too small then I would expect the runtime system to tell me that the heap is too small rather than blow up like this.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4982ghc-7.0.1: make install sets not enough permissions on library documentation2019-07-07T18:57:28ZLemmingghc-7.0.1: make install sets not enough permissions on library documentationI have installed GHC-7.0.1 from http://www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2
and installed it with 'configure' and 'sudo make install'.
I get:
```
$ ls -l /usr/local/share/doc/ghc/html/libraries/
drwx------...I have installed GHC-7.0.1 from http://www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2
and installed it with 'configure' and 'sudo make install'.
I get:
```
$ ls -l /usr/local/share/doc/ghc/html/libraries/
drwx------ 3 root root 4096 2011-02-26 20:23 array-0.3.0.2
drwx------ 3 root root 16384 2011-02-26 20:22 base-4.3.0.0
drwxr-xr-x 3 root root 4096 2011-02-26 20:23 bin-package-db-0.0.0.0
drwx------ 3 root root 4096 2011-02-26 20:23 bytestring-0.9.1.8
drwx------ 3 root root 12288 2011-02-26 20:23 Cabal-1.10.0.0
...
```
```
$ ls -l /usr/local/share/doc/ghc/html/
drwxr-xr-x 2 root root 4096 2011-02-26 20:24 Cabal
drwxr-xr-x 2 root root 4096 2011-02-26 20:24 haddock
drwx------ 4 root root 4096 2011-02-26 19:31 html
-rw-r--r-- 1 root root 1557 2011-02-26 20:24 index.html
drwxr-xr-x 66 root root 4096 2011-02-26 20:24 libraries
drwxr-xr-x 2 root root 4096 2011-02-26 20:24 users_guide
```
That is, the library documentation directories and /usr/local/share/doc/ghc/html/html/ have not enough permissions set for user access.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"ghc-7.0.1: make install sets not enough permissions on library documentation","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have installed GHC-7.0.1 from http://www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2\r\nand installed it with 'configure' and 'sudo make install'.\r\nI get:\r\n\r\n{{{\r\n$ ls -l /usr/local/share/doc/ghc/html/libraries/\r\ndrwx------ 3 root root 4096 2011-02-26 20:23 array-0.3.0.2\r\ndrwx------ 3 root root 16384 2011-02-26 20:22 base-4.3.0.0\r\ndrwxr-xr-x 3 root root 4096 2011-02-26 20:23 bin-package-db-0.0.0.0\r\ndrwx------ 3 root root 4096 2011-02-26 20:23 bytestring-0.9.1.8\r\ndrwx------ 3 root root 12288 2011-02-26 20:23 Cabal-1.10.0.0\r\n...\r\n}}}\r\n\r\n{{{\r\n$ ls -l /usr/local/share/doc/ghc/html/\r\ndrwxr-xr-x 2 root root 4096 2011-02-26 20:24 Cabal\r\ndrwxr-xr-x 2 root root 4096 2011-02-26 20:24 haddock\r\ndrwx------ 4 root root 4096 2011-02-26 19:31 html\r\n-rw-r--r-- 1 root root 1557 2011-02-26 20:24 index.html\r\ndrwxr-xr-x 66 root root 4096 2011-02-26 20:24 libraries\r\ndrwxr-xr-x 2 root root 4096 2011-02-26 20:24 users_guide\r\n}}}\r\n\r\nThat is, the library documentation directories and /usr/local/share/doc/ghc/html/html/ have not enough permissions set for user access.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4duncanduncan