Blocking MVar# primops not performing stack checks?

[Andreas Klebinger]

I just took a look at the implementation and it looks like you are right
Cheng.

I opened a ticket here: https://gitlab.haskell.org/ghc/ghc/issues/17893


Carter Schonwald schrieb am 02.03.2020 um 06:27:
> The simplest way to answer this is if you can help us construct a
> program, whether as Haskell or cmm, which tickles the failure you
> suspect is there ?
>
> The rts definitely gets less love overall.  And there’s fewer folks
> involved in those layers overall.
>
>
>
> On Wed, Feb 26, 2020 at 10:03 AM Shao, Cheng <cheng.shao at tweag.io
> <mailto:cheng.shao at tweag.io>> wrote:
>
>     Hi all,
>
>     When an MVar# primop blocks, it jumps to a function in
>     HeapStackCheck.cmm which pushes a RET_SMALL stack frame before
>     returning to the scheduler (e.g. the takeMVar# primop jumps to
>     stg_block_takemvar for stack adjustment). But these functions directly
>     bump Sp without checking for possible stack overflow, I wonder if it
>     is a bug?
>
>     Cheers,
>     Cheng
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200304/eee9e966/attachment.html>