Hey chessai,
Two comments:
- A segfault/runtime panic happening in GC does not mean there's a GC bug. You
can easily cause heap corruption with FFI or using unsafe primops, and it's
possible for those to cause a crash during GC.
- 8.6.5 is quite old, and we've fixed a few GC bugs since that version [1, 2,
3]. [3] is shipped with 8.10, others are only in HEAD currently. So if
possible it'd be good to run your program with 8.10, or even better, GHC HEAD,
and see if the problem persists.
You may want to use head.hackage [4] to make it easier to build your project
with GHC HEAD.
Hope that helps,
Ömer
[1]: https://gitlab.haskell.org/ghc/ghc/-/commit/390751768104cd3d2cb57e2037062916...
[2]: https://gitlab.haskell.org/ghc/ghc/-/commit/cfcc3c9a1f2e4e33bed4c40767f8e797...
[3]: https://gitlab.haskell.org/ghc/ghc/-/commit/0e57d8a106a61cac11bacb43633b8b4a...
[4]: http://ghc.gitlab.haskell.org/head.hackage/
chessai .
Hi devs,
A coworker is experiencing sporadic failures when reloading our project in GHCi, with
``` ghc: internal error: scavenge_one: strange object 23 (GHC version 8.6.5 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: repl failed for mercury-web-backend-0.0.0. The build process terminated with exit code -6 ```
upon a quick inspection it seems that scavenge_one inspects the type of the object, but has no case for BCO (which is 23). I'm guessing there's something weird going on here since this doesn't happen deterministically.
I don't have a good intuition for how this scavenging should work for BCO's, or if it should even be possible for BCO's to appear here (i.e. this is a symptom of some other bug).
Any thoughts?
Thanks _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs