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 > <[email protected]<javascript:_e({}, 'cvml', '[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]<javascript:_e({}, 'cvml', '[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]<javascript:_e({}, 'cvml', '[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
