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

[Carter Schonwald]

Not a problem.  We're always happy to find out that the standard tricks for
getting ghci to behave work on new problems!

On Saturday, September 28, 2013, Dominick Samperi wrote:

> 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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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/0f9399bc/attachment.htm>