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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dominick Samperi
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/2a9c4495/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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

Dominick Samperi
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/ebc95078/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

[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>

Reply | Threaded
Open this post in threaded view
|

[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>