[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial

[GHC]

#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 at 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