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 <[email protected]>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 <[email protected]>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 <[email protected]> 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@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 >>> >> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
