[GHC] #14626: No need to enter a scrutinised value

[GHC]

#14626: No need to enter a scrutinised value
-------------------------------------+-------------------------------------
        Reporter:  heisenbug         |                Owner:  heisenbug
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:  performance
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13861            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by heisenbug):

 Replying to [comment:18 heisenbug]:
 > [snippety]
 >
 > So this is my findings. Are strict fields able to hold blackholes?
 > And if so, why do they carry an `isEvaldUnfolding` when pattern matched
 against?
 >
 > Any hints appreciated! Do I have a (black)hole in my reasoning?
 >

 Following up my own question...

 I had luck and could set a few watchpoints in `lldb`, with the fourth one
 capturing the history of the `OccName`'s closure. I'll leave it here for
 the reference...
 {{{
 Watchpoint 4 hit:
 new value: 4313987056
 Process 2009 stopped
 * thread #1: tid = 0xa7e8d1, 0x0000000101223ddd
 libHSghc-8.5-ghc8.5.20180103.dylib`sxWx_info [inlined] _cA5r + 12 at
 BinIface.hs:149, queue = 'com.apple.main-thread', stop reason = watchpoint
 4
     frame #0: 0x0000000101223ddd
 libHSghc-8.5-ghc8.5.20180103.dylib`sxWx_info [inlined] _cA5r + 12 at
 BinIface.hs:149
    146
    147      -- Initialise the user-data field of bh
    148      bh <- do
 -> 149          bh <- return $ setUserData bh $ newReadState (error
 "getSymtabName")
    150
 (getDictFastString dict)
    151          symtab_p <- Binary.get bh     -- Get the symtab ptr
    152          data_p <- tellBin bh          -- Remember where we are now
 }}}
 This is presumably when the `OccName` got allocated on the heap.

 The next change happened here:
 {{{
 Watchpoint 4 hit:
 old value: 4313987056
 new value: 4463800616
 Process 2009 stopped
 * thread #1: tid = 0xa7e8d1, 0x000000010a104fc2 libHSrts_thr-
 ghc8.5.20180103.dylib`stg_upd_frame_info + 18, queue = 'com.apple.main-
 thread', stop reason = watchpoint 4
     frame #0: 0x000000010a104fc2 libHSrts_thr-
 ghc8.5.20180103.dylib`stg_upd_frame_info + 18
 libHSrts_thr-ghc8.5.20180103.dylib`stg_upd_frame_info:
 ->  0x10a104fc2 <+18>: movq   %rax, %rcx
     0x10a104fc5 <+21>: andq   $-0x100000, %rcx
     0x10a104fcc <+28>: movq   %rax, %rdx
     0x10a104fcf <+31>: andl   $0xff000, %edx
 }}}

 Let's disassemble the change:
 {{{
 (lldb) disassemble -s 4313987056
 libHSghc-8.5-ghc8.5.20180103.dylib`sxXT_info:
     0x1012237f0 <+0>:  leaq   -0x18(%rbp), %rax
     0x1012237f4 <+4>:  cmpq   %r15, %rax
     0x1012237f7 <+7>:  jb     0x10122388c               ; <+156> [inlined]
 _cA3D
     0x1012237fd <+13>: movq   0x1d6b6fc(%rip), %rax     ; (void
 *)0x000000010a104fb0: stg_upd_frame_info
     0x101223804 <+20>: movq   %rax, -0x10(%rbp)
     0x101223808 <+24>: movq   %rbx, -0x8(%rbp)
 }}}

 This gets overwritten with a BLACKHOLE:
 {{{
 (lldb) disassemble -s 4463800616
 libHSrts_thr-ghc8.5.20180103.dylib`stg_BLACKHOLE_info:
     0x10a103128 <+0>:  movq   0x8(%rbx), %rax
     0x10a10312c <+4>:  testb  $0x7, %al
     0x10a10312e <+6>:  jne    0x10a103230               ; <+264>
     0x10a103134 <+12>: movq   (%rax), %rcx
     0x10a103137 <+15>: cmpq   0x190c2(%rip), %rcx       ; (void
 *)0x000000010a1030c8: stg_IND_info
     0x10a10313e <+22>: je     0x10a103128               ; <+0>
     0x10a103140 <+24>: cmpq   0x19121(%rip), %rcx       ; (void
 *)0x000000010a103390: stg_TSO_info
 }}}

 Now, maybe the `Binary` instance breaks the invariant that the `n_occ`
 field is strict?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14626#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler