#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