[GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
           Reporter:  andrewchen     |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  highest        |         Milestone:
          Component:  Runtime        |           Version:  8.2.1
  System                             |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Runtime crash
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Test case: (compile with ghc 8.2.1 and -threaded option)
 {{{#!haskell
 module Main where

 import Control.Concurrent
 import Control.Monad
 import Data.Word
 import Foreign.Marshal.Alloc
 import Foreign.Ptr
 import Foreign.Storable

 foreign import ccall safe "test"
     c_test :: Ptr Word32 -> IO ()

 main :: IO ()
 main = do
     replicateM_ 1000 $ threadDelay 1000
     _ <- forkIO $ forever $ threadDelay 100
     allocaBytes 4 $ \p -> forever $ do
         c_test p
         x <- peek p
         unless (x == 0xDEADBEEF) $ putStrLn "value mismatch"
 }}}
 {{{#!c
 void test(unsigned int *buf) {
     *buf = 0xDEADBEEF;
 }
 }}}

 On my machine, it detects a few value mismatches before crashing with
 sigsegv.
 {{{
 $ time ./.stack-work/install/x86_64-linux-
 nopie/nightly-2017-10-10/8.2.1/bin/bug
 value mismatch
 value mismatch
 value mismatch
 value mismatch
 zsh: segmentation fault (core dumped)  ./.stack-work/install/x86_64-linux-
 nopie/nightly-2017-10-10/8.2.1/bin/bug
 ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug
 2.11s user 0.25s system 66% cpu 3.543 total
 }}}

 I believe this is what is causing crashes in xmobar. See discussion:
 https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar
 still happens without -threaded option, while this example only breaks
 when compiled with -threaded.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by andrewchen):

 * Attachment "ghc_output" added.

 compiler output with -v

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by RyanGlScott):

 * status:  new => infoneeded


Comment:

 For whatever reason, I'm not able to reproduce this on either my Ubuntu
 14.04 or 17.04 machines with GHC 8.2.1. I'm doing this:

 {{{
 $ ghc -fforce-recomp -threaded bug.c Bug.hs
 [1 of 1] Compiling Main             ( Bug.hs, Bug.o )
 Linking Bug ...
 $ ./Bug
 }}}

 It then proceeds to run forever (AFAICT) without hitting any `value
 mistmatch`es or segfaults.

 Some questions:

 1. What operating system are you using?
 2. How can I reproduce this issue //with just GHC//? Please, no
 instructions involving fancy build tools like `stack`, since if this
 really is a GHC bug, one should be able to trigger the issue with just
 GHC.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Thanks for your report andrewchan; Unfortunately, as with RyanGlScott, I
 am unable to reproduce this with `+RTS -N4`, `+RTS -N1`, or under any of
 GHC's optimization levels on Debian 9 running on amd64. Having a
 standalone testcase, free of build tools, would be quite helpful.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by andrewchen):

 I am running arch linux x64 on a i5-4200U laptop.

 I'm able to reproduce with just the system ghc:
 {{{
 ghc Main.hs test.c -threaded -O1 -fforce-recomp
 [1 of 1] Compiling Main             ( Main.hs, Main.o )
 Linking Main ...
 }}}

 For me the program fails within seconds:
 {{{
 $ time ./Main
 value mismatch
 value mismatch
 value mismatch
 value mismatch
 zsh: segmentation fault (core dumped)  ./Main
 ./Main  2.19s user 0.20s system 67% cpu 3.553 total
 }}}

 I'm also able to reproduce the issue in a fedora virtual machine on the
 same physical machine using ghc 8.2.1 binaries downloaded from
 haskell.org.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rezb1t):

 I can reproduce this same issue on my machine, I am using:
 NixOS x86_64 Unstable Branch (as of 10-12)
 GHC 8.2.1
 Binutils 2.28.1
 GCC 6.4.0

 I noticed the bug does not occur and the program runs infinitely if I
 simply compile with
 'ghc Main.hs test.c -threaded -o Bug', however, if Optimization level 1 or
 2 are enabled, the bug happens very quickly after running the binary.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by andrewchen):

 Also, I forgot to add, the bug does not occur when compiled with debug
 symbols (-g).

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Interesting; I can also reproduce this in my Nix unstable VM.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Somewhat to my surprise, this regression was introduced in
 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (`Join points`).

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Well, comment:7 certainly explains why `-g` avoids the crash: in 8.2
 source note ticks essentially prevented GHC from marking anything as a
 join point.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 I could have sworn I left a comment last night but it seems I am mistaken.
 Here is what I discovered while looking into this so far:

 The test is indeed rather environment sensitive. Moreover, as it doesn't
 occur under `rr` I strongly suspect it's a race of some sort. When
 compiled with `-debug` the eventual segmentation fault always seems to
 occur in `stg_putMVarzh`. Specifically here,
 {{{
 Dump of assembler code for function stg_putMVarzh:
    0x00000000004ab1b0 <+0>:     cmpl   $0x1,0x4f4800
    0x00000000004ab1b8 <+8>:     je     0x4ab35e <stg_putMVarzh+430>
    0x00000000004ab1be <+14>:    mov    $0x479e18,%eax
    0x00000000004ab1c3 <+19>:    mov    %rbx,%rcx
    0x00000000004ab1c6 <+22>:    sub    $0x8,%rsp
    0x00000000004ab1ca <+26>:    mov    %rcx,%rdi
    0x00000000004ab1cd <+29>:    mov    %rax,%rcx
    0x00000000004ab1d0 <+32>:    xor    %eax,%eax
    0x00000000004ab1d2 <+34>:    callq  *%rcx
    0x00000000004ab1d4 <+36>:    add    $0x8,%rsp
    0x00000000004ab1d8 <+40>:    cmpq   $0x4f2c30,0x18(%rbx)
    0x00000000004ab1e0 <+48>:    jne    0x4ab366 <stg_putMVarzh+438>
    0x00000000004ab1e6 <+54>:    mov    0x8(%rbx),%rcx
    0x00000000004ab1ea <+58>:    cmp    $0x4f2c30,%rcx
    0x00000000004ab1f1 <+65>:    je     0x4ab466 <stg_putMVarzh+694>
    0x00000000004ab1f7 <+71>:    cmpq   $0x4ac2f0,(%rcx)
    0x00000000004ab1fe <+78>:    je     0x4ab45d <stg_putMVarzh+685>
    0x00000000004ab204 <+84>:    cmpq   $0x4aca20,(%rcx)
    0x00000000004ab20b <+91>:    je     0x4ab45d <stg_putMVarzh+685>
    0x00000000004ab211 <+97>:    mov    0x10(%rcx),%rdx
    0x00000000004ab215 <+101>:   mov    0x8(%rcx),%rsi
    0x00000000004ab219 <+105>:   mov    %rsi,0x8(%rbx)
    0x00000000004ab21d <+109>:   cmpq   $0x4f2c30,0x8(%rbx)
    0x00000000004ab225 <+117>:   jne    0x4ab22f <stg_putMVarzh+127>
    0x00000000004ab227 <+119>:   movq   $0x4f2c30,0x10(%rbx)
 => 0x00000000004ab22f <+127>:   cmp    0x28(%rdx),%rbx
    0x00000000004ab233 <+131>:   je     0x4ab276 <stg_putMVarzh+198>
    ...
 }}}
 I believe this corresponds to this bit of C--,
 {{{#!c
     ...

     tso = StgMVarTSOQueue_tso(q);
     StgMVar_head(mvar) = StgMVarTSOQueue_link(q);
     if (StgMVar_head(mvar) == stg_END_TSO_QUEUE_closure) { // cmpq
 $0x4f2c30,0x8(%rbx)
         StgMVar_tail(mvar) = stg_END_TSO_QUEUE_closure; // movq
 $0x4f2c30,0x10(%rbx)
     }

     ASSERT(StgTSO_block_info(tso) == mvar);             // cmp
 0x28(%rdx),%rbx

     ...
 }}}

 Indeed we find that,
 {{{
 >>> print/a $rbx
 $1 = 0x42000b8400
 >>> print/a $rdx
 $2 = 0x42deadbeef
 }}}
 Yikes!

 This sounds to me like we reentered STG while forgetting to do some bit of
 cleanup from the foreign call.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by andrewchen):

 I managed to do a `rr` capture with `--chaos` mode.

 Here's the part in main where it does the comparison:
 {{{
 0x404581 <Main_main1_info+361>  mov    ecx,DWORD PTR [rax]
 0x404583 <Main_main1_info+363>  cmp    rcx,rbx                       //
 compares value with 0xDEADBEEF
 0x404586 <Main_main1_info+366>  jne    0x40443c <Main_main1_info+36> //
 goes to print "value mismatch"
 }}}
 {{{
 (rr) p/x $rcx
 $22 = 0x1
 (rr) p/x $rbx
 $23 = 0xdeadbeef
 (rr) p/x $rax
 $24 = 0x42000b7540
 }}}

 Putting a watch point on the the memory address and reverse continuing
 leads to this:
 {{{
 Old value = 1
 New value = -559038737
 0x0000000000470b42 in base_GHCziEventziPoll_new5_info ()
 => 0x0000000000470b42 <base_GHCziEventziPoll_new5_info+1218>:   49 89 04
 24     mov    QWORD PTR [r12],rax
 }}}
 {{{
 (rr) p/x $r12
 $27 = 0x42000b7540
 }}}

 Not sure what's going on there, but I hope this is of some help.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#14346: 8.2.1 regression: heap corruption after safe foreign calls
-------------------------------------+-------------------------------------
        Reporter:  andrewchen        |                Owner:  (none)
            Type:  bug               |               Status:  infoneeded
        Priority:  highest           |            Milestone:
       Component:  Runtime System    |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Indeed the `--chaos` tip is quite helpful. Thanks!

 So it appears that the crazy TSO is loaded in `stg_putMVar#` on line 1737:

 {{{#!c
     ...
     // There are readMVar/takeMVar(s) waiting: wake up the first one

     tso = StgMVarTSOQueue_tso(q);                                // <---
 here
     StgMVar_head(mvar) = StgMVarTSOQueue_link(q);
     if (StgMVar_head(mvar) == stg_END_TSO_QUEUE_closure) {
         StgMVar_tail(mvar) = stg_END_TSO_QUEUE_closure;
     }
 ...
 }}}
 Here `q` is `0x42000b7530` which is a fairly reasonable-looking
 `MVAR_TSO_QUEUE`, except with a completely wild `tso` field,
 {{{
 0x42000b7530:   0x4acd28 <stg_MVAR_TSO_QUEUE_info>      0x4f2c30
 0x42000b7540:   0x42deadbeef    0x433508 <base_GHCziInt_I32zh_con_info>
 }}}

 Indeed the last guy to write to `StgMVarTSOQueue_tso(q)` is the FFI
 target, `test`,
 {{{
 Dump of assembler code for function test:
 => 0x00000000004044f0 <+0>:     movl   $0xdeadbeef,(%rdi)
    0x00000000004044f6 <+6>:     retq
 }}}
 where `%rdi == 0x00000042000b7540`.

 Let's look at the calling sequence produced by GHC,
 {{{#!asm
 _c4Rp:
         movq $block_c4Ru_info,-8(%rbp) # I64[Sp - 8] = c4Ru;
         movq %rax,(%rbp)               # I64[Sp] = _s4Ok::I64;
         addq $-8,%rbp                  # Sp = Sp - 8;
         movq 872(%r13),%rbx            # _u4RJ::P64 = CurrentTSO;
         movq 24(%rbx),%rcx             # I64[I64[_u4RJ::P64 + 24] + 16] =
 Sp;
         movq %rbp,16(%rcx)
         movq 888(%r13),%rcx            # _u4RK::I64 = CurrentNursery;
         leaq 8(%r12),%rdx              # P64[_u4RK::I64 + 8] = Hp + 8;
             # I64[_u4RJ::P64 + 104] = I64[_u4RJ::P64 + 104]
             #                         - ((Hp + 8) - I64[_u4RK::I64]);
         movq %rdx,8(%rcx)
         leaq 8(%r12),%rdx
         subq (%rcx),%rdx
         movq 104(%rbx),%rcx
         subq %rdx,%rcx
         movq %rcx,104(%rbx)
             # (_u4RH::I64) = call "ccall" arg hints:  [PtrHint,]  result
 hints:  [PtrHint] suspendThread(BaseReg, 0);

         subq $8,%rsp                   # native-call stack adjustment
         movq %r13,%rdi                 # setup argument 1 (BaseReg)
         xorl %esi,%esi                 # setup argument 2 (0)
         movq %rax,%rbx                 # Save $rax in callee-saved
 register
         xorl %eax,%eax                 # ???
         call suspendThread
         addq $8,%rsp                   # undo stack adjustment
         subq $8,%rsp                   # redo stack adjustment; silly GHC
         movq %rbx,%rdi                 # ??? <---- This is where the bad
 argument comes from
         movq %rax,%rbx                 # Ahhh, I think I see
         xorl %eax,%eax
         call test                      # Native call
         addq $8,%rsp                   # undo stack adjustment
         subq $8,%rsp                   # you are such a joker, GHC
         movq %rbx,%rdi
         xorl %eax,%eax
         call resumeThread
         ...
 }}}

 It looks to me like what happens here is that we spill `$rax` (which
 contains a pointer to the current `MVar` closure) to `$rbx` twice, losing
 knowledge of the first spill. Consequently we end up passing the `MVar` as
 the argument to `test`. Hilarity ensues.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets