<div><div dir="auto">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 ? </div></div><div dir="auto"><br></div><div dir="auto">The rts definitely gets less love overall.  And there’s fewer folks involved in those layers overall.  </div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2020 at 10:03 AM Shao, Cheng <<a href="mailto:cheng.shao@tweag.io">cheng.shao@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
When an MVar# primop blocks, it jumps to a function in<br>
HeapStackCheck.cmm which pushes a RET_SMALL stack frame before<br>
returning to the scheduler (e.g. the takeMVar# primop jumps to<br>
stg_block_takemvar for stack adjustment). But these functions directly<br>
bump Sp without checking for possible stack overflow, I wonder if it<br>
is a bug?<br>
<br>
Cheers,<br>
Cheng<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>