[GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite

[GHC]

#15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 So I finally had a chance to reproduce this with a compiler built with
 debugging symbols. Interestingly, the first segfault I've seen crashed in
 this environment was in the SHA implementation itself:

 {{{
 Thread 2 received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16174.16189]
 0x000000000062aaae in sha256_do_chunk ()
 >>> disassemble
 Dump of assembler code for function sha256_do_chunk:
    0x000000000062a5d0 <+0>:     push   %r15
    0x000000000062a5d2 <+2>:     push   %r14
    0x000000000062a5d4 <+4>:     push   %r13
    0x000000000062a5d6 <+6>:     push   %r12
    0x000000000062a5d8 <+8>:     push   %rbp
    0x000000000062a5d9 <+9>:     push   %rbx
    0x000000000062a5da <+10>:    sub    $0x158,%rsp
    0x000000000062a5e1 <+17>:    mov    %fs:0x28,%rax
 ...
    0x000000000062aaa7 <+1239>:  pop    %r13
    0x000000000062aaa9 <+1241>:  pop    %r14
    0x000000000062aaab <+1243>:  pop    %r15
    0x000000000062aaad <+1245>:  retq
 => 0x000000000062aaae <+1246>:  movdqu (%rsi),%xmm0
    0x000000000062aab2 <+1250>:  lea    0x40(%r11),%rcx
    0x000000000062aab6 <+1254>:  mov    %r11,%rax
    0x000000000062aab9 <+1257>:  movaps %xmm0,0x40(%rsp)
 ...
 >>> bt
 #0  0x000000000062aaae in sha256_do_chunk ()
 #1  0x000000000062c05f in
 ghczuwrapperZC4ZCcryptohashzmsha256zm0zi11zi101zi0zminplaceZCCryptoziHashziSHA256ziFFIZChszucryptohashzusha256zuupdate
 ()
 #2  0x00000000006278a5 in s7zn_info ()
 #3  0x0000000000000000 in ?? ()
 }}}
 At first I suspected this was an alignment issue but no, `movdqu` is an
 unaligned move.

 The value of `$rsi` is quite suspicious:
 {{{
 >>> print /a $rsi
 $1 = 0x510000004200b85a
 }}}
 In fact, it seems that the crash occurs essentially as soon as we enter
 `sha256_do_chunk`. Tracing execution back into Haskell it looks like this
 crazy pointer comes from the C stack:
 {{{
 Dump of assembler code for function s7zn_info:
 ...
    0x0000000000627864 <+596>:   xor    %esi,%esi
    0x0000000000627866 <+598>:   mov    %rax,%r8
    0x0000000000627869 <+601>:   xor    %eax,%eax
    0x000000000062786b <+603>:   mov    %r8,%r14
    0x000000000062786e <+606>:   mov    %rdx,0x48(%rsp)           (B)
    0x0000000000627873 <+611>:   mov    %rcx,0x50(%rsp)
    0x0000000000627878 <+616>:   callq  0x7a2e00 <suspendThread>
    0x000000000062787d <+621>:   add    $0x8,%rsp
    0x0000000000627881 <+625>:   sub    $0x8,%rsp
 => 0x0000000000627885 <+629>:   mov    0x48(%rsp),%rcx           (A)
    0x000000000062788a <+634>:   mov    0x50(%rsp),%rdx
    0x000000000062788f <+639>:   add    %rdx,%rcx
    0x0000000000627892 <+642>:   mov    %rbx,%rdx
    0x0000000000627895 <+645>:   mov    %r14,%rdi
    0x0000000000627898 <+648>:   mov    %rcx,%rsi
    0x000000000062789b <+651>:   mov    %rax,%rbx
    0x000000000062789e <+654>:   xor    %eax,%eax
    0x00000000006278a0 <+656>:   callq  0x62c000
 <ghczuwrapperZC4ZCcryptohashzmsha256zm0zi11zi101zi0zminplaceZCCryptoziHashziSHA256ziFFIZChszucryptohashzusha256zuupdate>
 }}}
 Where the stack at point (A) looks like this,
 {{{
 >>> x/16a $rsp+0x38
 0x7f3f82107e18: 0x0     0x0
 0x7f3f82107e28: 0xa800000042004d27      0xa900000000006b33    <==== yikes
 0x7f3f82107e38: 0x42003e4301    0x42003e4310
 0x7f3f82107e48: 0x42003e43a1    0x42003e4909
 }}}
 Tracing further back I end up at point (B),
 {{{
 Continuing.

 Thread 2 hit Hardware watchpoint 1: *(void**) 0x7f3f82107e28

 Old value = (void *) 0xa800000042004d27
 New value = (void *) 0x42004e0d80
 0x000000000062786e in s7zn_info ()
 }}}
 Continuing to trace things back, it seems that these pointers are loaded
 from a stack frame,
 {{{
 >>> x/8a $rbx-1
 0x4200088130:   0x6b0550
 <bytestringzm0zi10zi8zi2_DataziByteStringziInternal_PS_con_info>
 0x520000000000a02d
 0x4200088140:   0xa800000042004d27      0xa900000000006b33
 0x4200088150:   0x6a00000042004d26      0x797f38
 <ghczmprim_GHCziTypes_ZC_con_info>
 0x4200088160:   0x4200088131    0x4200088118
 }}}

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