GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:04:54Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3206Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied2019-07-07T19:04:54ZDmitry123Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission deniedI have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error.....
\[root\@spot\]\# ghc
ghc-6.8.3: internal error: getMBlock: mmap: Perm...I have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error.....
\[root\@spot\]\# ghc
ghc-6.8.3: internal error: getMBlock: mmap: Permission denied
(GHC version 6.8.3 for x86_64_unknown_linux)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
<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 | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":["denied","getMBlock","mmap"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error..... \r\n\r\n\r\n[root@spot]# ghc\r\nghc-6.8.3: internal error: getMBlock: mmap: Permission denied\r\n (GHC version 6.8.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3098loadObj: failed2019-07-07T19:05:24ZrheinekeloadObj: failedI coded the `PrettyStub.hs` file as shown in the Real World Haskell, page 119 and loaded it into ghci. I then proceeded to follow the examples on page 120:
```
ghci>:load PrettyStub
[2 of 2] Compiling Main ( PrettyStub.hs, i...I coded the `PrettyStub.hs` file as shown in the Real World Haskell, page 119 and loaded it into ghci. I then proceeded to follow the examples on page 120:
```
ghci>:load PrettyStub
[2 of 2] Compiling Main ( PrettyStub.hs, interpreted )
Ok, modules loaded: SimpleJSON, Main.
ghci>:show modules
SimpleJSON ( SimpleJSON.hs, SimpleJSON.o )
Main ( PrettyStub.hs, interpreted )
ghci>:type undefined
undefined :: a
ghci>undefined
*** Exception: Prelude.undefined
ghci>double 3.14
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
loadObj: failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
And now I'm here.6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3045GHCI Crashes Under Windows when loading compiled code2019-07-07T19:05:40ZjburckGHCI Crashes Under Windows when loading compiled codewhenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
loadObj: failed
<details><summary>Trac metadata</summary>
...whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-unknown-mingw32):
loadObj: failed
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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 Crashes Under Windows when loading compiled code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened) \r\n\r\n(GHC version 6.10.1 for i386-unknown-mingw32): \r\n\r\nloadObj: failed \r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/2833internal error: throwTo: unrecognised why_blocked value2019-07-07T19:06:38Zlilacinternal error: throwTo: unrecognised why_blocked valueThe attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug!#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slow...The attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug!#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slows down dramatically (using \<10% CPU on each of my cores) and eventually crashes with:
```
Main: internal error: throwTo: unrecognised why_blocked value
(GHC version 6.10.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The change to reactive (from http://hpaste.org/12528\#a2) is to replace snapshotWith in FRP/Reactive/PrimRecursive.hs with:
```
snapshotWith :: forall a b c t. Ord t =>
(a -> b -> c) -> EventG t a -> ReactiveG t b -> EventG t c
snapshotWith f es rs = listEG . zip (eats es) . zipWith f (evals es) $ rats rs (eats es)
evals :: EventG t a -> [a]
evals (Event (Future (Max MaxBound, _))) = []
evals (Event (Future (_, ~(v `Stepper` es)))) = v:evals es
eats :: EventG t a -> [t]
eats (Event (Future (Max MaxBound, ~(_ `Stepper` es)))) = []
eats (Event (Future (Max (NoBound t), ~(_ `Stepper` es)))) = t:eats es
eats (Event (Future (Max MinBound, ~(_ `Stepper` es)))) = eats es
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/2658Extreme memory usage (probably type functions)2019-07-07T19:07:28ZguestExtreme memory usage (probably type functions)This is with the ghc 6.10.1 rc:
http://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a
Then a perf build.
Then, wget http://hackage.haskell.org/pac...This is with the ghc 6.10.1 rc:
http://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a
Then a perf build.
Then, wget http://hackage.haskell.org/packages/archive/sessions/2008.7.18/sessions-2008.7.18.tar.gz, unpack and cd sessions-2008.7.18
ghci-6.8.3 Tests/Tests.hs. This takes 40 seconds to get to the prompt and uses about 700MB memory.
ghci-6.10.0.20081004 Tests/Tests.hs. This has not finished type checking yet (well over 5 mins now - it exhaused my 4GB RAM and is now eating its way through 16GB of swap). top reports it's currently using about 5GB memory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.9 |
| 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":"Extreme memory usage","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is with the ghc 6.10.1 rc:\r\n\r\nhttp://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs-testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a\r\n\r\nThen a perf build.\r\n\r\nThen, wget http://hackage.haskell.org/packages/archive/sessions/2008.7.18/sessions-2008.7.18.tar.gz, unpack and cd sessions-2008.7.18\r\n\r\nghci-6.8.3 Tests/Tests.hs. This takes 40 seconds to get to the prompt and uses about 700MB memory.\r\n\r\nghci-6.10.0.20081004 Tests/Tests.hs. This has not finished type checking yet (well over 5 mins now - it exhaused my 4GB RAM and is now eating its way through 16GB of swap). top reports it's currently using about 5GB memory.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/454hPutBuf doesn't respect LineBuffering2019-07-07T19:17:54ZSimon MarlowhPutBuf doesn't respect LineBuffering```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newA...```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newArray)
> import System.IO (hSetBinaryMode, hPutBuf, stdout,
hSetBuffering,
> BufferMode(..))
>
> main = do hSetBinaryMode stdout True
> hSetBuffering stdout LineBuffering
> p <- newArray (map castCharToCChar "foo\n")
> hPutBuf stdout p 4
> system "sleep 5"
> putStr "bar\n"
> --------------------------------------------------
>
> compiled by GHC then it waits 5 seconds and then
prints foo and bar
> together.
>
> With hugs, foo is printed and then 5 seconds later
bar is printed, as
> I would expect.
True, the implementation doesn't respect LineBuffering
(though it does
respect the other buffering modes, I believe). That's
a bug.
```6.12.1