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

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
#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
#include #include 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@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR rwbarton@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

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
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
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
#include #include 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@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR rwbarton@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

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
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
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
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
#include #include 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@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR rwbarton@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

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
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
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
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
#include #include 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@adjunction:/tmp$ gcc -o pt pt.c -lpthread -lR rwbarton@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
participants (2)
-
Carter Schonwald
-
Dominick Samperi