GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:46:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8039RTS linker: unloadObj() does not actually unload the code2019-07-07T18:46:43ZSimon MarlowRTS linker: unloadObj() does not actually unload the codeWe've known about this for a long time, but it hasn't been a pressing issue in GHCi. The problem with actually unloading code is that there might be pointers into it from the heap or other RTS data structures, so we need to do a full hea...We've known about this for a long time, but it hasn't been a pressing issue in GHCi. The problem with actually unloading code is that there might be pointers into it from the heap or other RTS data structures, so we need to do a full heap traversal to discover whether it is safe to unload code or not.
This is an issue for a project at Facebook that needs to have long running processes that regularly unload and load code using the RTS linker, and right now the process grows over time.
This ticket is to track the issue, and I'm also working on a fix. The same problem affects the dynamic linker, although I'm not planning to fix that (yet).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RTS linker: unloadObj() does not actually unload the code","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We've known about this for a long time, but it hasn't been a pressing issue in GHCi. The problem with actually unloading code is that there might be pointers into it from the heap or other RTS data structures, so we need to do a full heap traversal to discover whether it is safe to unload code or not.\r\n\r\nThis is an issue for a project at Facebook that needs to have long running processes that regularly unload and load code using the RTS linker, and right now the process grows over time.\r\n\r\nThis ticket is to track the issue, and I'm also working on a fix. The same problem affects the dynamic linker, although I'm not planning to fix that (yet).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8038Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_642019-07-07T18:46:44ZawsonOld-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64make install fails with
```
Installing library in G:/Progs/MSys/local/lib\old-time-1.1.0.1
ghc-cabal.exe: Error: Could not find module: System.Time with any suffix:
```
<details><summary>Trac metadata</summary>
| Trac field ...make install fails with
```
Installing library in G:/Progs/MSys/local/lib\old-time-1.1.0.1
ghc-cabal.exe: Error: Could not find module: System.Time with any suffix:
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/old-time |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64","status":"New","operating_system":"","component":"libraries/old-time","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"make install fails with\r\n{{{\r\nInstalling library in G:/Progs/MSys/local/lib\\old-time-1.1.0.1\r\nghc-cabal.exe: Error: Could not find module: System.Time with any suffix:\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8035STM transaction left open if there is an orElse on the path between throwSTM ...2019-07-07T18:46:45ZerrgeSTM transaction left open if there is an orElse on the path between throwSTM and catchSTM```
main = join $ atomically $ do
catchSTM
(throwSTM ThreadKilled `orElse` return (putStrLn "wtf"))
(\(e::SomeException) -> return (putStrLn "ok"))
```
This program crashes with a segmentation fault. Tested with GHC HEAD.
I ...```
main = join $ atomically $ do
catchSTM
(throwSTM ThreadKilled `orElse` return (putStrLn "wtf"))
(\(e::SomeException) -> return (putStrLn "ok"))
```
This program crashes with a segmentation fault. Tested with GHC HEAD.
I attach the testcase and my proposed fix for the issue. I've run the fast testsuite with the proposed fix without new defects. On the other hand I'm very new to GHC, so while I'm sure in the defect and the test, the fix may be bogus.
Thanks goes to Mihály Bárász for discovering the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| 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":"STM transaction left open if there is an orElse on the path between throwSTM and catchSTM","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["rts","stm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nmain = join $ atomically $ do\r\n catchSTM\r\n (throwSTM ThreadKilled `orElse` return (putStrLn \"wtf\"))\r\n (\\(e::SomeException) -> return (putStrLn \"ok\"))\r\n\r\n}}}\r\n\r\nThis program crashes with a segmentation fault. Tested with GHC HEAD.\r\n\r\nI attach the testcase and my proposed fix for the issue. I've run the fast testsuite with the proposed fix without new defects. On the other hand I'm very new to GHC, so while I'm sure in the defect and the test, the fix may be bogus.\r\n\r\nThanks goes to Mihály Bárász for discovering the issue.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8004Applicative/Monad proposal related warnings (AMP phase 1)2019-07-07T18:46:52ZquchenApplicative/Monad proposal related warnings (AMP phase 1)Add ad-hoc warnings to GHC telling the user about the following:\[\[BR\]\]
- Instance of `Monad` without instances of `Functor`/`Applicative`\[\[BR\]\]
- Instance of `MonadPlus` without instance of `Alternative`\[\[BR\]\]
- Module define...Add ad-hoc warnings to GHC telling the user about the following:\[\[BR\]\]
- Instance of `Monad` without instances of `Functor`/`Applicative`\[\[BR\]\]
- Instance of `MonadPlus` without instance of `Alternative`\[\[BR\]\]
- Module defines functions named `(<*>)`, `pure` or `join`
Refactoring code to remove these warnings makes sure the AMP will not break the module in the future. Since they are basically meta-deprecations, I would suggest treating them similar to ordinary deprecations.
This is part of phase 1 of the Applicative/Monad proposal (AMP), as discussed on the mailing lists \[1\]; a more detailed description of the AMP is available on the Wiki \[2\].
\[1\]: [http://article.gmane.org/gmane.comp.lang.haskell.libraries/19482](http://article.gmane.org/gmane.comp.lang.haskell.libraries/19482)
\[2\]: [http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal](http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Applicative/Monad proposal related warnings (AMP phase 1)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Add ad-hoc warnings to GHC telling the user about the following:[[BR]]\r\n- Instance of `Monad` without instances of `Functor`/`Applicative`[[BR]]\r\n- Instance of `MonadPlus` without instance of `Alternative`[[BR]]\r\n- Module defines functions named `(<*>)`, `pure` or `join`\r\n\r\nRefactoring code to remove these warnings makes sure the AMP will not break the module in the future. Since they are basically meta-deprecations, I would suggest treating them similar to ordinary deprecations.\r\n\r\n\r\n\r\nThis is part of phase 1 of the Applicative/Monad proposal (AMP), as discussed on the mailing lists [1]; a more detailed description of the AMP is available on the Wiki [2].\r\n\r\n[1]: [http://article.gmane.org/gmane.comp.lang.haskell.libraries/19482]\r\n[2]: [http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal]","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1quchenquchenhttps://gitlab.haskell.org/ghc/ghc/-/issues/7970Thread GC frees roots before thread actually finishes2019-07-07T18:47:13ZjoeyadamsThread GC frees roots before thread actually finishesIn the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed:
```
import Control.Exception as E
import Data.IORef
import System.Mem.Weak
main :: IO ()
main = do
ref <- new...In the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed:
```
import Control.Exception as E
import Data.IORef
import System.Mem.Weak
main :: IO ()
main = do
ref <- newIORef 'x'
weak <- mkWeakIORef ref $ putStrLn "IORef finalized"
let check = deRefWeak weak >>= \m -> case m of
Nothing -> putStrLn "IORef was GCed"
Just ref' -> do
x <- readIORef ref'
putStrLn $ "IORef still alive, and contains " ++ show x
let loop = loop
check
loop `catch` \ex -> do
putStrLn $ "caught exception: " ++ show (ex :: SomeException)
check
readIORef ref >>= print
```
Output:
```
IORef still alive, and contains 'x'
IORef finalized
caught exception: <<loop>>
IORef was GCed
'x'
```
The same happens with other thread deadlocks, such as:
- newEmptyMVar \>\>= takeMVar
- atomically retry
It does not happen when a `StackOverflow` or `UserInterrupt` exception is caught.
This also affects `ForeignPtr`; see the attached "database" example. This is what really triggered #7170. I marked this "Runtime crash" because it can lead to a `ForeignPtr` being accessed after the garbage collector finalized it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"Thread GC frees roots before thread actually finishes","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed:\r\n\r\n{{{\r\nimport Control.Exception as E\r\nimport Data.IORef\r\nimport System.Mem.Weak\r\n\r\nmain :: IO ()\r\nmain = do\r\n ref <- newIORef 'x'\r\n weak <- mkWeakIORef ref $ putStrLn \"IORef finalized\"\r\n let check = deRefWeak weak >>= \\m -> case m of\r\n Nothing -> putStrLn \"IORef was GCed\"\r\n Just ref' -> do\r\n x <- readIORef ref'\r\n putStrLn $ \"IORef still alive, and contains \" ++ show x\r\n let loop = loop\r\n check\r\n loop `catch` \\ex -> do\r\n putStrLn $ \"caught exception: \" ++ show (ex :: SomeException)\r\n check\r\n readIORef ref >>= print\r\n}}}\r\n\r\nOutput:\r\n\r\n{{{\r\nIORef still alive, and contains 'x'\r\nIORef finalized\r\ncaught exception: <<loop>>\r\nIORef was GCed\r\n'x'\r\n}}}\r\n\r\nThe same happens with other thread deadlocks, such as:\r\n\r\n * newEmptyMVar >>= takeMVar\r\n\r\n * atomically retry\r\n\r\nIt does not happen when a `StackOverflow` or `UserInterrupt` exception is caught.\r\n\r\nThis also affects `ForeignPtr`; see the attached \"database\" example. This is what really triggered #7170. I marked this \"Runtime crash\" because it can lead to a `ForeignPtr` being accessed after the garbage collector finalized it.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7918SrcSpan's associated with expanded quasi-quotes are inconsistent2019-07-07T18:47:27Zedsko@edsko.netSrcSpan's associated with expanded quasi-quotes are inconsistentConsider
```
{-# LANGUAGE TemplateHaskell #-}
module A where
import Language.Haskell.TH.Quote
qq = QuasiQuoter {
quoteExp = \str -> case str of
"a" -> [| True |]
...Consider
```
{-# LANGUAGE TemplateHaskell #-}
module A where
import Language.Haskell.TH.Quote
qq = QuasiQuoter {
quoteExp = \str -> case str of
"a" -> [| True |]
"b" -> [| id True |]
"c" -> [| True || False |]
"d" -> [| False |]
, quotePat = undefined
, quoteType = undefined
, quoteDec = undefined
}
{-# LANGUAGE QuasiQuotes #-}
module B where
import A
ex1 = [qq|a|]
ex2 = [qq|b|]
ex3 = [qq|c|]
ex4 = [qq|d|]
```
In the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi-quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the "contents" of the quasi-quote.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| 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":"SrcSpan's associated with expanded quasi-quotes are inconsistent","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\nimport Language.Haskell.TH.Quote\r\nqq = QuasiQuoter {\r\n quoteExp = \\str -> case str of\r\n \"a\" -> [| True |]\r\n \"b\" -> [| id True |]\r\n \"c\" -> [| True || False |]\r\n \"d\" -> [| False |]\r\n , quotePat = undefined\r\n , quoteType = undefined\r\n , quoteDec = undefined\r\n }\r\n\r\n\r\n{-# LANGUAGE QuasiQuotes #-}\r\nmodule B where\r\nimport A\r\nex1 = [qq|a|]\r\nex2 = [qq|b|]\r\nex3 = [qq|c|]\r\nex4 = [qq|d|]\r\n}}}\r\n\r\nIn the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi-quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the \"contents\" of the quasi-quote. \r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7914base library's MD5 symbols clash with others2019-07-07T18:47:28Zbosbase library's MD5 symbols clash with othersWe have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but di...We have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but different ABIs.
Depending on the order in which the linker runs across the object files, we end up with a crash during application startup as a result of one component picking up the other component's MD5 symbols.
The offending source file is libraries/base/cbits/md5.c.
A simple fix for this would be to prefix the function names with e.g. _ghc_ or something similar, so that the names would not clash.
There are perhaps other functions in base (probably many others) that could benefit from a similar treatment, but we're not crashing on those yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"base library's MD5 symbols clash with others","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but different ABIs.\r\n\r\nDepending on the order in which the linker runs across the object files, we end up with a crash during application startup as a result of one component picking up the other component's MD5 symbols.\r\n\r\nThe offending source file is libraries/base/cbits/md5.c.\r\n\r\nA simple fix for this would be to prefix the function names with e.g. _ghc_ or something similar, so that the names would not clash.\r\n\r\nThere are perhaps other functions in base (probably many others) that could benefit from a similar treatment, but we're not crashing on those yet.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7889Build Error (master branch)2019-07-07T18:47:39Zcg31Build Error (master branch)I got this error while building the master branch.
System is Windows 8 64-bit. Code grabbed from github.
```
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... ghc-stage2.exe: panic! (the 'impossible' happene...I got this error while building the master branch.
System is Windows 8 64-bit. Code grabbed from github.
```
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... ghc-stage2.exe: panic! (the 'impossible' happened)
(GHC version 7.7.20130504 for i386-unknown-mingw32):
loadArchive "z:\\Lang\\Haskell\\ghc_files\\git\\libraries\\integer-gmp\\dist-install\\build\\libHSinteger-gmp-0.5.1.0.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
ghc-stage2.exe: Unknown PEi386 section name `.drectve' (while processing: z:\Lang\Haskell\ghc_files\git\libraries\integer-gmp\dist-install\build\libHSinteger-gmp-0.5.1.0.a)
make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1
make: *** [all] Error 2
```7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7864--make -dynamic-too doesn't work2019-07-07T18:47:46ZIan Lynagh <igloo@earth.li>--make -dynamic-too doesn't work`--make -dynamic-too` doesn't work yet.
I think that the best fix will be to unify the two different code paths that `-c` and `--make` use to do more-or-less the same thing (the Hsc phase).
In the mean-time, this means that Cabal can't...`--make -dynamic-too` doesn't work yet.
I think that the best fix will be to unify the two different code paths that `-c` and `--make` use to do more-or-less the same thing (the Hsc phase).
In the mean-time, this means that Cabal can't use -dynamic-too, so I've marked it as not supported in `compilerInfo` in `DynFlags`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"--make -dynamic-too doesn't work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`--make -dynamic-too` doesn't work yet.\r\n\r\nI think that the best fix will be to unify the two different code paths that `-c` and `--make` use to do more-or-less the same thing (the Hsc phase).\r\n\r\nIn the mean-time, this means that Cabal can't use -dynamic-too, so I've marked it as not supported in `compilerInfo` in `DynFlags`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7852panic: kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}2019-07-07T18:47:49ZIan Lynagh <igloo@earth.li>panic: kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}This code:
```
f :: (Num Int => Num) () => ()
f = undefined
```
make ghc panic:
```
$ ghci q.hs
GHCi, version 7.7.20130421: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package intege...This code:
```
f :: (Num Int => Num) () => ()
f = undefined
```
make ghc panic:
```
$ ghci q.hs
GHCi, version 7.7.20130421: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( q.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130421 for x86_64-unknown-linux):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic: kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code:\r\n{{{\r\nf :: (Num Int => Num) () => ()\r\nf = undefined\r\n}}}\r\nmake ghc panic:\r\n{{{\r\n$ ghci q.hs\r\nGHCi, version 7.7.20130421: 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\n[1 of 1] Compiling Main ( q.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.7.20130421 for x86_64-unknown-linux):\r\n kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7834dyn way and INTEGER_LIBRARY=integer-simple2019-07-07T18:47:53ZGabor Greifdyn way and INTEGER_LIBRARY=integer-simplea standard bootstrap with
```
perl boot
./configure
make INTEGER_LIBRARY=integer-simple
```
causes some problems:
1. there is a panic (at least when `-j4`) "fromJust..." (which strangely disappears on the second attempt)
1. `__word_en...a standard bootstrap with
```
perl boot
./configure
make INTEGER_LIBRARY=integer-simple
```
causes some problems:
1. there is a panic (at least when `-j4`) "fromJust..." (which strangely disappears on the second attempt)
1. `__word_encode{Float|Double}` is not found by the linker. There are `__int_encode{Float|Double}` symbols available, though, and changing the source helps for linking, but not for correctness, obviously.
I'll add specific details (if not trivially reproducible) as soon as I am back at my dev machine.
The bottom line is that since GHC HEAD now builds the 'dyn' way by default, this kind of bootstrap always fails. Normally not a problem on desktop linux, but in combination with a gmp-less embedded linux and cross-compiling it becomes annoying.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"dyn way and INTEGER_LIBRARY=integer-simple","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"a standard bootstrap with\r\n{{{\r\nperl boot\r\n./configure\r\nmake INTEGER_LIBRARY=integer-simple\r\n}}}\r\ncauses some problems:\r\n 1. there is a panic (at least when `-j4`) \"fromJust...\" (which strangely disappears on the second attempt)\r\n 2. `__word_encode{Float|Double}` is not found by the linker. There are `__int_encode{Float|Double}` symbols available, though, and changing the source helps for linking, but not for correctness, obviously.\r\n\r\nI'll add specific details (if not trivially reproducible) as soon as I am back at my dev machine.\r\n\r\nThe bottom line is that since GHC HEAD now builds the 'dyn' way by default, this kind of bootstrap always fails. Normally not a problem on desktop linux, but in combination with a gmp-less embedded linux and cross-compiling it becomes annoying.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7833installed GHC refers to libffi in the build directory2019-07-07T18:47:54ZIan Lynagh <igloo@earth.li>installed GHC refers to libffi in the build directoryIn #7806, Kazu reported that on OS X:
After "make install", the installed GHC refers to libffi in the build directory.
```
% otool -L ghc | grep libffi
/Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility versi...In #7806, Kazu reported that on OS X:
After "make install", the installed GHC refers to libffi in the build directory.
```
% otool -L ghc | grep libffi
/Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0)
```
So, after I did "make maintainer-clean", the installed GHC could not find a libffi.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"installed GHC refers to libffi in the build directory","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In #7806, Kazu reported that on OS X:\r\n\r\nAfter \"make install\", the installed GHC refers to libffi in the build directory.\r\n{{{\r\n% otool -L ghc | grep libffi\r\n\r\n /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0)\r\n}}}\r\nSo, after I did \"make maintainer-clean\", the installed GHC could not find a libffi.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7819FreeBSD without system libffi: Shared object "libffi.so.6" not found2019-07-07T18:47:57ZIan Lynagh <igloo@earth.li>FreeBSD without system libffi: Shared object "libffi.so.6" not foundIn #7806, kazu-yamamoto reported that on FreeBSD without a system libffi:
GHC can be built:
```
% make maintainer-clean
% perl boot
% ./configure --prefix=/ghc-head \
--with-iconv-includes=/usr/local/include \
...In #7806, kazu-yamamoto reported that on FreeBSD without a system libffi:
GHC can be built:
```
% make maintainer-clean
% perl boot
% ./configure --prefix=/ghc-head \
--with-iconv-includes=/usr/local/include \
--with-iconv-libraries=/usr/local/lib \
--with-gmp-includes=/usr/local/include \
--with-gmp-libraries=/usr/local/lib \
--with-gcc=/usr/local/bin/gcc47 \
--with-gcc-4.2=/usr/local/bin/gcc47
% gmake -j10
```
But installation fails:
```
% gmake install
Installing library in /ghc-head/lib/ghc-7.7.20130323/haskell2010-1.1.1.0
"/ghc-head/lib/ghc-7.7.20130323/bin/ghc-pkg" --force --global-package-db "/ghc-head/lib/ghc-7.7.20130323/package.conf.d" update rts/package.conf.install
Shared object "libffi.so.6" not found, required by "libHSrts-ghc7.7.20130323.so"
gmake[1]: *** [install_packages] Error 1
gmake: *** [install] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FreeBSD without system libffi: Shared object \"libffi.so.6\" not found","status":"New","operating_system":"Unknown/Multiple","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In #7806, kazu-yamamoto reported that on FreeBSD without a system libffi:\r\n\r\nGHC can be built:\r\n\r\n{{{\r\n% make maintainer-clean\r\n% perl boot\r\n% ./configure --prefix=/ghc-head \\\r\n --with-iconv-includes=/usr/local/include \\\r\n --with-iconv-libraries=/usr/local/lib \\\r\n --with-gmp-includes=/usr/local/include \\\r\n --with-gmp-libraries=/usr/local/lib \\\r\n --with-gcc=/usr/local/bin/gcc47 \\\r\n --with-gcc-4.2=/usr/local/bin/gcc47\r\n% gmake -j10\r\n}}}\r\n\r\nBut installation fails:\r\n\r\n{{{\r\n% gmake install\r\nInstalling library in /ghc-head/lib/ghc-7.7.20130323/haskell2010-1.1.1.0\r\n\"/ghc-head/lib/ghc-7.7.20130323/bin/ghc-pkg\" --force --global-package-db \"/ghc-head/lib/ghc-7.7.20130323/package.conf.d\" update rts/package.conf.install\r\nShared object \"libffi.so.6\" not found, required by \"libHSrts-ghc7.7.20130323.so\"\r\ngmake[1]: *** [install_packages] Error 1\r\ngmake: *** [install] Error 2\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/7814panic in PPC NCG2019-07-07T18:47:58ZGabor Greifpanic in PPC NCGI get panics in the NCG PPC register allocator while compiling these files:
```
rts_dist_HC rts/dist/build/StgStdThunks.dyn_o
rts_dist_HC rts/dist/build/StgStdThunks.thr_dyn_o
rts_dist_HC rts/dist/build/StgStdThunks.l_dyn_o
rts_...I get panics in the NCG PPC register allocator while compiling these files:
```
rts_dist_HC rts/dist/build/StgStdThunks.dyn_o
rts_dist_HC rts/dist/build/StgStdThunks.thr_dyn_o
rts_dist_HC rts/dist/build/StgStdThunks.l_dyn_o
rts_dist_HC rts/dist/build/StgStdThunks.thr_l_dyn_o
HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o
HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o
HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o
```
The panic message is like this:
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.7.20130405 for powerpc-montavista-linux):
allocateRegsAndSpill: Cannot read from uninitialized register
%vI_nff
```
This makes the bootstapping of PPC cross compiler, ehm, delicate.
There is a comment in compiler/nativeGen/RegAlloc/Linear/Main.hs:756
```
Nothing | reading ->
pprPanic "allocateRegsAndSpill: Cannot read from uninitialized register" (ppr r)
-- NOTE: if the input to the NCG contains some
-- unreachable blocks with junk code, this panic
-- might be triggered. Make sure you only feed
-- sensible code into the NCG. In CmmPipeline we
-- call removeUnreachableBlocks at the end for this
-- reason.
```
So we have a 'junk code' issue here.
Any hints how I can debug this?7.8.1Gabor GreifGabor Greifhttps://gitlab.haskell.org/ghc/ghc/-/issues/7807Parse error with "where" and file-ending comment2019-07-07T18:48:01ZRichard Eisenbergrae@richarde.devParse error with "where" and file-ending commentConsider the following file:
```
{-# LANGUAGE TypeFamilies #-}
type family F a
type instance where
F Int = Bool
{-
-}
```
If there is a file-ending newline, after the comment, the file parses. If there is not a file-ending newline...Consider the following file:
```
{-# LANGUAGE TypeFamilies #-}
type family F a
type instance where
F Int = Bool
{-
-}
```
If there is a file-ending newline, after the comment, the file parses. If there is not a file-ending newline, I get a parse error.
I wrote the code dealing with `type instance where` notation, but this seems more related to parsing issues (which I know little about) than `type instance where`. Please correct me if I'm wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parse error with \"where\" and file-ending comment","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following file:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family F a\r\ntype instance where\r\n F Int = Bool\r\n\r\n{-\r\n\r\n-}\r\n}}}\r\n\r\nIf there is a file-ending newline, after the comment, the file parses. If there is not a file-ending newline, I get a parse error.\r\n\r\nI wrote the code dealing with {{{type instance where}}} notation, but this seems more related to parsing issues (which I know little about) than {{{type instance where}}}. Please correct me if I'm wrong.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7799Assembly error while building GHC 7.72019-07-07T18:48:06ZIcelandjackAssembly error while building GHC 7.7While building GHC 7.7 (after running `make') I got this error message:
{{{
$ "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-pack...While building GHC 7.7 (after running `make') I got this error message:
{{{
$ "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o
<braries/base/dist-install/build/System/Posix/Internals.dyn_o
ghc23405_0.c: Assembler messages:
ghc23405_0.c:127:0:
Error: junk `.get_pc_thunk.bx' after expression
ghc23405_0.c:153:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:181:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:207:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:235:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:261:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:285:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:311:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:339:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:367:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:393:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:421:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:449:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:477:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:505:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:525:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:526:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:527:0: Error: Missing symbol name in directive
ghc23405_0.c:527:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:528:0: Error: Missing symbol name in directive
\[1\] baldur\@baldur-lappi:\~/ghc\> "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o
\<braries/base/dist-install/build/System/Posix/Internals.dyn_o
ghc23405_0.c: Assembler messages:
ghc23405_0.c:127:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:153:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:181:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:207:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:235:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:261:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:285:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:311:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:339:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:367:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:393:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:421:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:449:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:477:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:505:0:
> Error: junk \`.get_pc_thunk.bx' after expression
ghc23405_0.c:525:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:526:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:527:0: Error: Missing symbol name in directive
ghc23405_0.c:527:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:528:0: Error: Missing symbol name in directive
ghc23405_0.c:528:0:
> Error: junk at end of line, first unrecognized character is \`.'
ghc23405_0.c:529:0:
> Error: junk at end of line, first unrecognized character is \`1'
ghc23405_0.c:528:0:
> Error: junk at end of line, first unrecognized character is \`.'
ghc23405_0.c:529:0:
> Error: junk at end of line, first unrecognized character is \`1'
}}}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Assembly error while building GHC 7.7","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While building GHC 7.7 (after running `make') I got this error message:\r\n\r\n{{{\r\n$ \"inplace/bin/ghc-stage1\" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o \r\n<braries/base/dist-install/build/System/Posix/Internals.dyn_o \r\nghc23405_0.c: Assembler messages:\r\n\r\nghc23405_0.c:127:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:153:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:181:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:207:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:235:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:261:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:285:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:311:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:339:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:367:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:393:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:421:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:449:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:477:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:505:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:525:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:526:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:527:0: Error: Missing symbol name in directive\r\n\r\nghc23405_0.c:527:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:528:0: Error: Missing symbol name in directive\r\n[1] baldur@baldur-lappi:~/ghc> \"inplace/bin/ghc-stage1\" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o \r\n<braries/base/dist-install/build/System/Posix/Internals.dyn_o \r\nghc23405_0.c: Assembler messages:\r\n\r\nghc23405_0.c:127:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:153:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:181:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:207:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:235:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:261:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:285:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:311:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:339:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:367:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:393:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:421:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:449:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:477:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:505:0:\r\n Error: junk `.get_pc_thunk.bx' after expression\r\n\r\nghc23405_0.c:525:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:526:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:527:0: Error: Missing symbol name in directive\r\n\r\nghc23405_0.c:527:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:528:0: Error: Missing symbol name in directive\r\n\r\nghc23405_0.c:528:0:\r\n Error: junk at end of line, first unrecognized character is `.'\r\n\r\nghc23405_0.c:529:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n\r\nghc23405_0.c:528:0:\r\n Error: junk at end of line, first unrecognized character is `.'\r\n\r\nghc23405_0.c:529:0:\r\n Error: junk at end of line, first unrecognized character is `1'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7787modifyMVar does not restore value if callback returns error value2019-07-07T18:48:09ZjoeyadamsmodifyMVar does not restore value if callback returns error value`modifyMVar` is currently implemented as follows:
```
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
mask $ \restore -> do
a <- takeMVar m
(a',b) <- restore (io a) `onException` putMVar m a
putMVar ...`modifyMVar` is currently implemented as follows:
```
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
mask $ \restore -> do
a <- takeMVar m
(a',b) <- restore (io a) `onException` putMVar m a
putMVar m a'
return b
```
The problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example:
```
> import Control.Concurrent.MVar
> mv <- newMVar 'x'
> modifyMVar mv $ \_ -> return undefined
*** Exception: Prelude.undefined
> withMVar mv print
-- hang --
```
Perhaps we can fix it like this:
```
- (a',b) <- restore (io a) `onException` putMVar m a
+ (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| 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":"modifyMVar does not restore value if callback returns error value","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`modifyMVar` is currently implemented as follows:\r\n\r\n{{{\r\nmodifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b\r\nmodifyMVar m io =\r\n mask $ \\restore -> do\r\n a <- takeMVar m\r\n (a',b) <- restore (io a) `onException` putMVar m a\r\n putMVar m a'\r\n return b\r\n}}}\r\n\r\nThe problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example:\r\n\r\n{{{\r\n> import Control.Concurrent.MVar\r\n> mv <- newMVar 'x'\r\n> modifyMVar mv $ \\_ -> return undefined\r\n*** Exception: Prelude.undefined\r\n> withMVar mv print\r\n-- hang --\r\n}}}\r\n\r\nPerhaps we can fix it like this:\r\n\r\n{{{\r\n- (a',b) <- restore (io a) `onException` putMVar m a\r\n+ (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7772Finish support for DYNAMIC_GHC_PROGRAMS on Windows2019-07-07T18:48:13ZIan Lynagh <igloo@earth.li>Finish support for DYNAMIC_GHC_PROGRAMS on WindowsFinish support for `DYNAMIC_GHC_PROGRAMS` on Windows.
```
#include <stdarg.h>
#include <stdio.h>
#include <Windows.h>
#include <Shlwapi.h>
#include "Rts.h"
LPTSTR path_dirs[] = {
TEXT("libraries/haskeline/dist-install/build"),
...Finish support for `DYNAMIC_GHC_PROGRAMS` on Windows.
```
#include <stdarg.h>
#include <stdio.h>
#include <Windows.h>
#include <Shlwapi.h>
#include "Rts.h"
LPTSTR path_dirs[] = {
TEXT("libraries/haskeline/dist-install/build"),
TEXT("compiler/stage2/build"),
TEXT("ghc/stage2/build/tmp"),
TEXT("libraries/transformers/dist-install/build"),
TEXT("libraries/template-haskell/dist-install/build"),
TEXT("libraries/hpc/dist-install/build"),
TEXT("libraries/hoopl/dist-install/build"),
TEXT("libraries/bin-package-db/dist-install/build"),
TEXT("libraries/binary/dist-install/build"),
TEXT("libraries/Cabal/Cabal/dist-install/build"),
TEXT("libraries/process/dist-install/build"),
TEXT("libraries/pretty/dist-install/build"),
TEXT("libraries/directory/dist-install/build"),
TEXT("libraries/time/dist-install/build"),
TEXT("libraries/old-locale/dist-install/build"),
TEXT("libraries/filepath/dist-install/build"),
TEXT("libraries/Win32/dist-install/build"),
TEXT("libraries/containers/dist-install/build"),
TEXT("libraries/bytestring/dist-install/build"),
TEXT("libraries/deepseq/dist-install/build"),
TEXT("libraries/array/dist-install/build"),
TEXT("libraries/base/dist-install/build"),
TEXT("libraries/integer-gmp/dist-install/build"),
TEXT("libraries/ghc-prim/dist-install/build"),
TEXT("rts/dist/build"),
NULL
};
void die(char *fmt, ...) {
va_list argp;
fprintf(stderr, "error: ");
va_start(argp, fmt);
vfprintf(stderr, fmt, argp);
va_end(argp);
fprintf(stderr, "\n");
exit(1);
}
void setPath(void) {
LPTSTR *dir;
LPTSTR path;
int n;
int len = 0;
LPTSTR exePath, s;
HMODULE hExe;
hExe = GetModuleHandle(NULL);
if (hExe == NULL) {
die("GetModuleHandle failed");
}
exePath = malloc(10000); // XXX
GetModuleFileName(hExe, exePath, 10000); // XXX
for(s = exePath; *s != '\0'; s++) {
if (*s == '\\') {
*s = '/';
}
}
s = StrRChr(exePath, NULL, '/');
if (s == NULL) {
die("No directory separator in executable path: %s", exePath);
}
s[0] = '\0';
n = s - exePath;
for (dir = path_dirs; *dir != NULL; dir++) {
len += n + 7/* /../../ */ + lstrlen(*dir) + 1/* semicolon */;
}
len++; // NUL
path = malloc(10000); // XXX
s = path;
for (dir = path_dirs; *dir != NULL; dir++) {
StrCpy(s, exePath);
s += n;
StrCpy(s, "/../../");
s += 7;
StrCpy(s, *dir);
s += lstrlen(*dir);
s[0] = ';';
s++;
}
s[0] = '\0';
if (! SetEnvironmentVariable(TEXT("PATH"), path)) {
printf("SetEnvironmentVariable failed (%d)\n", GetLastError());
}
}
HINSTANCE loadDll(LPTSTR dll) {
HINSTANCE h;
DWORD dw;
LPVOID lpMsgBuf;
h = LoadLibrary(dll);
if (h == NULL) {
dw = GetLastError();
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );
die("loadDll failed: %d: %s\n", dw, lpMsgBuf);
}
return h;
}
void *GetNonNullProcAddress(HINSTANCE h, char *sym) {
void *p;
p = GetProcAddress(h, sym);
if (p == NULL) {
die("Failed to find address for %s", sym);
}
return p;
}
HINSTANCE GetNonNullModuleHandle(LPTSTR dll) {
HINSTANCE h;
h = GetModuleHandle(dll);
if (h == NULL) {
die("Failed to get module handle for %s", dll);
}
return h;
}
typedef int (*hs_main_t)(int , char **, StgClosure *, RtsConfig);
int main(int argc, char *argv[]) {
void *p;
HINSTANCE hRtsDll, hProgDll;
StgClosure *main_p;
RtsConfig *rts_config_p;
hs_main_t hs_main_p;
setPath();
// hRtsDll = loadDll(TEXT("libHSrts_debug-ghc7.7.20130315.dll"));
// hRtsDll = loadDll(TEXT("libHSrts_thr-ghc7.7.20130315.dll"));
// hRtsDll = loadDll(TEXT("libHSrts-ghc7.7.20130315.dll"));
hProgDll = loadDll(TEXT("ghc-stage2.exe.dll"));
hRtsDll = GetNonNullModuleHandle(TEXT("libHSrts-ghc7.7.20130315.dll"));
hs_main_p = GetNonNullProcAddress(hRtsDll, "hs_main");
rts_config_p = GetNonNullProcAddress(hRtsDll, "defaultRtsConfig");
main_p = GetNonNullProcAddress(hProgDll, "ZCMain_main_closure");
return hs_main_p(argc, argv, main_p, *rts_config_p);
}
```
Gives:
```
Segmentation fault/access violation in generated code
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Finish support for DYNAMIC_GHC_PROGRAMS on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Finish support for `DYNAMIC_GHC_PROGRAMS` on Windows.\r\n\r\n{{{\r\n#include <stdarg.h>\r\n#include <stdio.h>\r\n#include <Windows.h>\r\n#include <Shlwapi.h>\r\n\r\n#include \"Rts.h\"\r\n\r\nLPTSTR path_dirs[] = {\r\n TEXT(\"libraries/haskeline/dist-install/build\"),\r\n TEXT(\"compiler/stage2/build\"),\r\n TEXT(\"ghc/stage2/build/tmp\"),\r\n TEXT(\"libraries/transformers/dist-install/build\"),\r\n TEXT(\"libraries/template-haskell/dist-install/build\"),\r\n TEXT(\"libraries/hpc/dist-install/build\"),\r\n TEXT(\"libraries/hoopl/dist-install/build\"),\r\n TEXT(\"libraries/bin-package-db/dist-install/build\"),\r\n TEXT(\"libraries/binary/dist-install/build\"),\r\n TEXT(\"libraries/Cabal/Cabal/dist-install/build\"),\r\n TEXT(\"libraries/process/dist-install/build\"),\r\n TEXT(\"libraries/pretty/dist-install/build\"),\r\n TEXT(\"libraries/directory/dist-install/build\"),\r\n TEXT(\"libraries/time/dist-install/build\"),\r\n TEXT(\"libraries/old-locale/dist-install/build\"),\r\n TEXT(\"libraries/filepath/dist-install/build\"),\r\n TEXT(\"libraries/Win32/dist-install/build\"),\r\n TEXT(\"libraries/containers/dist-install/build\"),\r\n TEXT(\"libraries/bytestring/dist-install/build\"),\r\n TEXT(\"libraries/deepseq/dist-install/build\"),\r\n TEXT(\"libraries/array/dist-install/build\"),\r\n TEXT(\"libraries/base/dist-install/build\"),\r\n TEXT(\"libraries/integer-gmp/dist-install/build\"),\r\n TEXT(\"libraries/ghc-prim/dist-install/build\"),\r\n TEXT(\"rts/dist/build\"),\r\n NULL\r\n};\r\n\r\nvoid die(char *fmt, ...) {\r\n va_list argp;\r\n\r\n fprintf(stderr, \"error: \");\r\n va_start(argp, fmt);\r\n vfprintf(stderr, fmt, argp);\r\n va_end(argp);\r\n fprintf(stderr, \"\\n\");\r\n\r\n exit(1);\r\n}\r\n\r\nvoid setPath(void) {\r\n LPTSTR *dir;\r\n LPTSTR path;\r\n int n;\r\n int len = 0;\r\n LPTSTR exePath, s;\r\n HMODULE hExe;\r\n\r\n hExe = GetModuleHandle(NULL);\r\n if (hExe == NULL) {\r\n die(\"GetModuleHandle failed\");\r\n }\r\n exePath = malloc(10000); // XXX\r\n GetModuleFileName(hExe, exePath, 10000); // XXX\r\n for(s = exePath; *s != '\\0'; s++) {\r\n if (*s == '\\\\') {\r\n *s = '/';\r\n }\r\n }\r\n s = StrRChr(exePath, NULL, '/');\r\n if (s == NULL) {\r\n die(\"No directory separator in executable path: %s\", exePath);\r\n }\r\n s[0] = '\\0';\r\n n = s - exePath;\r\n\r\n for (dir = path_dirs; *dir != NULL; dir++) {\r\n len += n + 7/* /../../ */ + lstrlen(*dir) + 1/* semicolon */;\r\n }\r\n len++; // NUL\r\n\r\n path = malloc(10000); // XXX\r\n s = path;\r\n for (dir = path_dirs; *dir != NULL; dir++) {\r\n StrCpy(s, exePath);\r\n s += n;\r\n StrCpy(s, \"/../../\");\r\n s += 7;\r\n StrCpy(s, *dir);\r\n s += lstrlen(*dir);\r\n s[0] = ';';\r\n s++;\r\n }\r\n s[0] = '\\0';\r\n\r\n if (! SetEnvironmentVariable(TEXT(\"PATH\"), path)) {\r\n printf(\"SetEnvironmentVariable failed (%d)\\n\", GetLastError());\r\n }\r\n}\r\n\r\nHINSTANCE loadDll(LPTSTR dll) {\r\n HINSTANCE h;\r\n DWORD dw;\r\n LPVOID lpMsgBuf;\r\n\r\n h = LoadLibrary(dll);\r\n\r\n if (h == NULL) {\r\n dw = GetLastError();\r\n FormatMessage(\r\n FORMAT_MESSAGE_ALLOCATE_BUFFER |\r\n FORMAT_MESSAGE_FROM_SYSTEM |\r\n FORMAT_MESSAGE_IGNORE_INSERTS,\r\n NULL,\r\n dw,\r\n MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),\r\n (LPTSTR) &lpMsgBuf,\r\n 0, NULL );\r\n die(\"loadDll failed: %d: %s\\n\", dw, lpMsgBuf);\r\n }\r\n\r\n return h;\r\n}\r\n\r\nvoid *GetNonNullProcAddress(HINSTANCE h, char *sym) {\r\n void *p;\r\n\r\n p = GetProcAddress(h, sym);\r\n if (p == NULL) {\r\n die(\"Failed to find address for %s\", sym);\r\n }\r\n return p;\r\n}\r\n\r\nHINSTANCE GetNonNullModuleHandle(LPTSTR dll) {\r\n HINSTANCE h;\r\n\r\n h = GetModuleHandle(dll);\r\n if (h == NULL) {\r\n die(\"Failed to get module handle for %s\", dll);\r\n }\r\n return h;\r\n}\r\n\r\ntypedef int (*hs_main_t)(int , char **, StgClosure *, RtsConfig);\r\n\r\nint main(int argc, char *argv[]) {\r\n void *p;\r\n HINSTANCE hRtsDll, hProgDll;\r\n\r\n StgClosure *main_p;\r\n RtsConfig *rts_config_p;\r\n hs_main_t hs_main_p;\r\n\r\n setPath();\r\n\r\n // hRtsDll = loadDll(TEXT(\"libHSrts_debug-ghc7.7.20130315.dll\"));\r\n // hRtsDll = loadDll(TEXT(\"libHSrts_thr-ghc7.7.20130315.dll\"));\r\n // hRtsDll = loadDll(TEXT(\"libHSrts-ghc7.7.20130315.dll\"));\r\n hProgDll = loadDll(TEXT(\"ghc-stage2.exe.dll\"));\r\n hRtsDll = GetNonNullModuleHandle(TEXT(\"libHSrts-ghc7.7.20130315.dll\"));\r\n\r\n hs_main_p = GetNonNullProcAddress(hRtsDll, \"hs_main\");\r\n rts_config_p = GetNonNullProcAddress(hRtsDll, \"defaultRtsConfig\");\r\n main_p = GetNonNullProcAddress(hProgDll, \"ZCMain_main_closure\");\r\n\r\n return hs_main_p(argc, argv, main_p, *rts_config_p);\r\n}\r\n}}}\r\n\r\nGives:\r\n{{{\r\nSegmentation fault/access violation in generated code\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7752GHC as a library documentation out of sync2019-07-07T18:48:18ZtibbeGHC as a library documentation out of syncThe example program(s) at
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html
no longer compile. The docs probably just need a bit of tweaking.
<details><summary>Trac metadata</summary>
| Trac field ...The example program(s) at
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html
no longer compile. The docs probably just need a bit of tweaking.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.6.2 |
| 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":"GHC as a library documentation out of sync","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The example program(s) at\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html\r\n\r\nno longer compile. The docs probably just need a bit of tweaking.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7715threadDelay causes segfault on Mac if compiled by 32bit GHC2019-07-07T18:48:26Zkazu-yamamotothreadDelay causes segfault on Mac if compiled by 32bit GHCThe following code causes segfault
```
main :: IO ()
main = do
replicateM_ 100 $ forkIO $ do
threadDelay 1000000
putStrLn "Hello, world!"
threadDelay 5000000
```
if compiled with 32bit GHC head on Mac.
64bit G...The following code causes segfault
```
main :: IO ()
main = do
replicateM_ 100 $ forkIO $ do
threadDelay 1000000
putStrLn "Hello, world!"
threadDelay 5000000
```
if compiled with 32bit GHC head on Mac.
64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux.
"gdb" caught the following on each run:
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000005
[Switching to process 51076 thread 0x20b]
0x00000005 in ?? ()
```
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000019
[Switching to process 50933 thread 0x20b]
0x00000019 in ?? ()
```
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x40e40348
[Switching to process 51004 thread 0x20b]
0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay causes segfault on Mac if compiled by 32bit GHC","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The following code causes segfault\r\n{{{\r\nmain :: IO ()\r\nmain = do\r\n replicateM_ 100 $ forkIO $ do\r\n threadDelay 1000000 \r\n putStrLn \"Hello, world!\"\r\n threadDelay 5000000\r\n}}}\r\nif compiled with 32bit GHC head on Mac.\r\n\r\n64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux.\r\n\r\n\"gdb\" caught the following on each run:\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_PROTECTION_FAILURE at address: 0x00000005\r\n[Switching to process 51076 thread 0x20b]\r\n0x00000005 in ?? ()\r\n}}}\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_PROTECTION_FAILURE at address: 0x00000019\r\n[Switching to process 50933 thread 0x20b]\r\n0x00000019 in ?? ()\r\n}}}\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_INVALID_ADDRESS at address: 0x40e40348\r\n[Switching to process 51004 thread 0x20b]\r\n0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1