#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: newcomer => * status: patch => infoneeded * cc: ezyang (added) Comment: Ok, here is some insight. The problem is related to trivial bindings – whether they are literals or nullary data cons. The latter are easy to produce, so here is what I did: I first broke `cpe_ExprIsLiteral`, by adding this as a new first clause {{{ cpe_ExprIsTrivial (Var v) | isDataConWorkId v = False }}} Then I compiled the smallest possible program (with `-dcore-lint -dstg- lint`) {{{#!hs main = return () }}} and it crashes. Here the output with `+RTS -Dg`: {{{ cap 0: initialised allocated 1 megablock(s) at 0x4200000000 allocated 1 megablock(s) at 0x4200100000 ---------------------------------------------------------- Gen Max Mut-list Blocks Large Live Slop Blocks Bytes Objects ---------------------------------------------------------- 0 0 0 1 0 0 4096 1 0 0 1 0 0 4096 ---------------------------------------------------------- 0 8192 ---------------------------------------------------------- cap 0: starting GC GC (gen 1, using 1 thread(s)) Memory inventory: gen 0 blocks : 11 blocks ( 0.0 MB) gen 1 blocks : 2 blocks ( 0.0 MB) nursery : 256 blocks ( 1.0 MB) retainer : 0 blocks ( 0.0 MB) arena blocks : 0 blocks ( 0.0 MB) exec : 0 blocks ( 0.0 MB) GC free pool : 0 blocks ( 0.0 MB) free : 235 blocks ( 0.9 MB) total : 504 blocks ( 2.0 MB) cap 0: GC working scavenging static objects T11158: internal error: evacuate(static): strange closure type 38956 (GHC version 8.1.20161012 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abgebrochen }}} So some pointer from the set of static objects is broken by this change. We are in a slightly better position than above because we no longer need to use ghc-the-library to trigger the crash. But still, the problem could be anywhere in the libraries. Here is the backtrace: {{{ (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff70dd40a in __GI_abort () at abort.c:89 #2 0x00000000006d041a in rtsFatalInternalErrorFn (s=0x7525c0 "evacuate(static): strange closure type %d", ap=0x7fffffffdbf8) at rts/RtsMessages.c:182 #3 0x00000000006d004c in barf (s=0x7525c0 "evacuate(static): strange closure type %d") at rts/RtsMessages.c:46 #4 0x00000000006f2cc3 in evacuate (p=0x986158) at rts/sm/Evac.c:562 #5 0x0000000000717f18 in scavenge_static () at rts/sm/Scav.c:1764 #6 0x00000000007184d9 in scavenge_loop () at rts/sm/Scav.c:2088 #7 0x00000000006ee6a4 in scavenge_until_all_done () at rts/sm/GC.c:1001 #8 0x00000000006ed6cc in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=0, cap=0x9d0d80 <MainCapability>) at rts/sm/GC.c:404 #9 0x00000000006dc686 in scheduleDoGC (pcap=0x7fffffffdf10, task=0x9e9ce0, force_major=rtsTrue) at rts/Schedule.c:1821 #10 0x00000000006dd1a5 in exitScheduler (wait_foreign=rtsFalse) at rts/Schedule.c:2636 #11 0x00000000006d09c2 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:326 #12 0x00000000006d0b7a in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:483 #13 0x00000000006e5312 in hs_main (argc=1, argv=0x7fffffffe178, main_closure=0x97d670, rts_config=...) at rts/RtsMain.c:91 #14 0x0000000000404226 in main () }}} But at this time of day, I will not dig in deeper. Edward, does this analysis provide any insight to you? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11158#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler