<div dir="ltr">Upon further investigation:<div><br></div><div>    <i>"The FFI spec requires the implementation to support re-initialising itself after being shut down with hs_exit(), but GHC does not currently support that."</i></div><div>    <a href="https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/bugs-and-infelicities.html#infelicities-ffi">https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/bugs-and-infelicities.html#infelicities-ffi</a><br></div><div><br></div><div>So it's a known issue / shortcoming.</div><div><br></div><div>-Karl Cronburg-</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 2:41 PM, Karl Cronburg <span dir="ltr"><<a href="mailto:karl.cronburg@gmail.com" target="_blank">karl.cronburg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was having the same problem a while back. If you turn on debugging symbols and give it to gdb, you<div>get that the seg fault is happening when the RTS attempts to allocate after the second initialization:<div><br></div><div><div>    Program received signal SIGSEGV, Segmentation fault.</div><div>    0xf7f6f4f9 in allocate (cap=cap@entry=0xf7f92b40 <MainCapability>, n=n@entry=2) at rts/sm/Storage.c:812</div><div>    812<span style="white-space:pre-wrap">      </span>rts/sm/Storage.c: No such file or directory.</div><div>    (gdb) bt</div><div>    #0  0xf7f6f4f9 in allocate (cap=cap@entry=0xf7f92b40 <MainCapability>, n=n@entry=2) at rts/sm/Storage.c:812</div><div>    #1  0xf7f5c603 in rts_mkInt32 (cap=0xf7f92b40 <MainCapability>, i=-11921) at rts/RtsAPI.c:69</div><div>    #2  0xf7cdea7a in pointer_test () from ../../ia32/build/<a href="http://libHSpads-haskell-1.1-6fKCdLtCMO82em71etbiu1-ghc7.10.2.so" target="_blank">libHSpads-haskell-1.1-6fKCdLtCMO82em71etbiu1-ghc7.10.2.so</a></div><div>    #3  0x5655579c in main (argc=1, argv=0xffffd244) at Pointer.c:11</div></div><div><br></div><div>So my solution was to just leave the RTS initialized. What's the downside of leaving it initialized throughout</div></div><div>the entire execution of your program? If the RTS / GC is smart enough it should know not to waste time</div><div>doing a GC when no Haskell code has been run?</div><div><br></div><div>I too would be interested though in being able to clean up the RTS from C when I know no Haskell code will</div><div>be run again anytime soon.</div><div><br></div><div>-Karl Cronburg-</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Dec 2, 2015 at 1:58 PM, Alp Mestanogullari <span dir="ltr"><<a href="mailto:alpmestan@gmail.com" target="_blank">alpmestan@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div><div>Hello everyone,<br><br></div>I'm currently calling Haskell code from C. My goal is to apply a Haskell function to each element of some dataset that I get from outside Haskell-land. For now, before I make this fancier and more efficient, the plan is to just bring the RTS up with hs_init, call my Haskell function (exporter to C with 'foreign export ccall [...]') on the element and finally shut the RTS down, doing this for every element.<br><br></div>When running this, I realized the RTS was running into a segfault when calling the Haskell function on the second element. This led me to believe it wasn't possible to call hs_init()/hs_exit() multiple times in the same program. But then I checked the Haskell 2010 report, FFI section [1], and it says:<br><br><div style="margin-left:40px"><i>The function <span>hs_init()</span> initialises the Haskell system and
provides it with the available command line arguments. Upon return, the arguments solely intended for the Haskell
runtime system are removed (i.e., the values that <span>argc</span> and <span>argv</span> point to may have changed). This function must be
called during program startup before any Haskell function is invoked; otherwise, the system behaviour is undefined.
Conversely, the Haskell system is deinitialised by a call to <span>hs_exit()</span>. Multiple invocations of <span>hs_init()</span> are
permitted, provided that they are followed by an equal number of calls to <span>hs_exit()</span> and that the first call to
<span>hs_exit()</span> is after the last call to <span>hs_init()</span>. In addition to nested calls to <span>hs_init()</span>, the Haskell
system may be de-initialised with <span>hs_exit()</span> and be re-initialised with <span>hs_init()</span> at a later point in
time. This ensures that repeated initialisation due to multiple libraries being implemented in Haskell is
covered.
 </i><br></div><br></div>Which means, if I understand correctly, that what I want, while very inefficient, should work fine.<br><br></div>I've put together a minimal example that exhibits the problem, which can be found at <a href="https://github.com/alpmestan/simple-c-export" target="_blank">https://github.com/alpmestan/simple-c-export</a> :<br><br>- <a href="https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c" target="_blank">https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c</a> shows the C code that brings the RTS up and down, with some printf statements to show what's going on.<br><br>- <a href="https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs" target="_blank">https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs</a> shows the trivial Haskell function I'm exposing.<br><br>- <a href="https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal" target="_blank">https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.cabal</a> contains the build options I'm compiling the code with<br><br></div>When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always get:<br><br><div style="margin-left:40px">$ cabal run simple-c<br>Preprocessing executable 'simple-c' for simple-c-export-0.1...<br>Linking dist/build/simple-c/simple-c ...<br>Running simple-c...<br>#0 - Launching RTS...<br>#0 - RTS started! Calling Haskell function...<br>0<br>#0 - Killing RTS now...<br>#0 - RTS killed!<br>#1 - Launching RTS...<br>#1 - RTS started! Calling Haskell function...<br>Segmentation fault: 11<br></div><br></div>Is there something special I should do to make this work, that I'm overlooking? Or is this a bug (that I should report on Trac, I guess) ?<br><br></div>Thanks in advance for any clarification on this.<span><font color="#888888"><br clear="all"><div><div><div><div><div><div><div><div><br>-- <br><div>Alp Mestanogullari</div>
</div></div></div></div></div></div></div></div></font></span></div>
<br></div></div>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>