[GHC] #8371: ghci byte compiler + FFI crashes when used with embedded R

[Dominick Samperi]

I hope my last two postings to ghc-devs did not create too much noise,
as I intended them to go to a comment thread in ghc-tickets (I realize
now that I need to do this outside of gmail).

It appears that replies to comments in ghc-tickets from gmail are
automatically routed to ghc-devs, potentially showing comments
out of context. Sorry.

Dominick


On Sat, Sep 28, 2013 at 10:35 AM, Dominick Samperi <djsamperi at gmail.com>wrote:

> After further testing it appears this work-around is not enough.
> It needs to be combined with another suggestion in this
> thread: must use ghc-7.7. There is a segfault (but no
> "C stack usage" message) when ghc-7.6.3 is used.
>
> Thank you!
>
>
>
> On Sat, Sep 28, 2013 at 10:08 AM, Dominick Samperi <djsamperi at gmail.com>wrote:
>
>> Thanks! Turning off R's stack limit checks will not work. I tried this
>> and this leads to a segfault. Fortunately, your experiments led me
>> to a work-around: simply use the -fno-ghci-sandbox flag.
>>
>> R is not thread-safe, and this flag tells ghci to run computations
>> in the main thread instead of forking.
>>
>>
>> On Sat, Sep 28, 2013 at 1:29 AM, GHC <ghc-devs at haskell.org> wrote:
>>
>>> #8371: ghci byte compiler + FFI crashes when used with embedded R
>>> -------------------------------+----------------------------------
>>>         Reporter:  dsamperi    |            Owner:
>>>             Type:  bug         |           Status:  new
>>>         Priority:  normal      |        Milestone:
>>>        Component:  GHCi        |          Version:  7.6.3
>>>       Resolution:              |         Keywords:
>>> Operating System:  Linux       |     Architecture:  x86_64 (amd64)
>>>  Type of failure:  GHCi crash  |       Difficulty:  Unknown
>>>        Test Case:              |       Blocked By:
>>>         Blocking:              |  Related Tickets:
>>> -------------------------------+----------------------------------
>>>
>>> Comment (by rwbarton):
>>>
>>>  I can reproduce this without ghci, by putting a forkIO around the body
>>> of
>>>  main (and adding a threadDelay in the main thread).
>>>
>>>  It seems to just be an interaction between R's method for determining
>>> the
>>>  base address of the stack and the way pthread allocates stacks for new
>>>  threads. Try this C example program `pt.c`.
>>>
>>>  {{{
>>>  #include <stdio.h>
>>>  #include <unistd.h>
>>>  #include <pthread.h>
>>>
>>>  int Rf_initEmbeddedR(int argc, char **argv);
>>>
>>>  void *foo(void *blah)
>>>  {
>>>      char *args[] = {"pt", "--gui=none", "--silent", "--vanilla"};
>>>      int r;
>>>      setenv("R_HOME", "/usr/lib/R", 1);
>>>      r = Rf_initEmbeddedR(sizeof(args)/sizeof(args[0]), args);
>>>      printf("r = %d\n", r);
>>>  }
>>>
>>>  int main(void)
>>>  {
>>>      pthread_t tid;
>>>      pthread_create(&tid, NULL, foo, NULL);
>>>      while (1)
>>>          sleep(1);
>>>      return 0;
>>>  }
>>>  }}}
>>>
>>>  {{{
>>>  rwbarton at adjunction:/tmp$ gcc -o pt pt.c  -lpthread -lR
>>>  rwbarton at adjunction:/tmp$ ./pt
>>>  Error: C stack usage is too close to the limit
>>>  Error: C stack usage is too close to the limit
>>>  r = 1
>>>  }}}
>>>
>>>  It would probably be best to just disable R's stack limit checks, if
>>>  possible.
>>>
>>> --
>>> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8371#comment:6>
>>> GHC <http://www.haskell.org/ghc/>
>>> The Glasgow Haskell Compiler
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130928/e81e3324/attachment.htm>