Opened 7 months ago

Closed 7 months ago

#8371 closed bug (invalid)

ghci byte compiler + FFI crashes when used with embedded R

Reported by: dsamperi Owned by:
Priority: normal Milestone:
Component: GHCi Version: 7.6.3
Keywords: Cc: hvr
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: GHCi crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:


The ghci interpreter destroys the C stack when initializing embedded R (the statistical
software system available at There is no problem using
embedded R with ghc (compiled code). I have had no problems using ghci with other FFI projects, and this does not appear to be a linking problem (there are no undefined references).

To reproduce the problem (under Fedora Linux using ghc 7.6.3) download the R source code, unpack, and (using haskellRtest.hs is attached):

  1. cd R-3.0.2
  2. ./configure --enable-R-shlib
  3. make
  4. make install
  5. cd <haskelltestdir>
  6. ghci -L/usr/local/lib64/R/lib -lR haskellRtest.hs
  7. Main> main

Initialize R session...
Error: C stack usage is too close to the limit


  1. No computations are done, the failure happens during startup.
  2. The C functions called are in <R source>/src/unix/Rembedded.c
  3. The error message is issued from <R source>/src/main/errors.c
  4. I tried increasing the system level C stack size limit but this didn't help.
  5. As noted above, there are no problems when ghc is used.

Attachments (1)

haskellRtest.hs (937 bytes) - added by dsamperi 7 months ago.

Download all attachments as: .zip

Change History (9)

Changed 7 months ago by dsamperi

comment:1 Changed 7 months ago by rwbarton

Does it work when you compile with the threaded runtime, like ghci uses? (ghc -threaded haskellRtest.hs -L/usr/local/lib64/R/lib -lR should do it)

comment:2 Changed 7 months ago by dsamperi

It works with the command line you provide here, but as I noted in the report there
are no problems when ghc is used. When I try to use -threaded with ghci I get the warning
"-debug, -threaded and -ticky are ignored by GHCi".

comment:3 Changed 7 months ago by dsamperi

This is just a stab in the dark, but while reviewing the docs on FFI I discovered that it is
assumed ints can be used for 64-bit addressing, that is, the difference between two pointer
values can be stored in an int. But under Windows this is not so (32-bit ints), and I think
R also employs 32-bit ints. If this is the source of the problem then it should show up
in both ghc and ghci, but it does not. Again, just a stab in the dark...

comment:4 Changed 7 months ago by carter

Have you tried testing to see if the problem also happens with ghc head ?
Ghci prior to 7.7 has it's own custom linker and is the culprit behind many ghci specific bugs.

comment:5 Changed 7 months ago by dsamperi

Thanks for the suggestion. I tried to build from HEAD but it requires Happy 1.19, and
only version 1.18 would install (due to a global constraint?). So I used the lazy
method of downloading a pre-built binary for Linux from, specifically,
I installed from ghc-7.7.20130720-x86_64-unknown-linux.tar.bz2.

Unfortunately, this did not resolve the problem, as I still get the
C stack usage Error.

comment:6 Changed 7 months ago 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)
    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.

comment:7 Changed 7 months ago by dsamperi

I accidentally replied to you in gmail (sent to ghc-devs) instead of in this comment
thread, sorry! Your comment combined with the suggestion that I use ghc-7.7 provides
a work-around.

I tried disabling R's stack limit checks, but this leads to a segfault.

A correct workaround is to use the flag -fno-ghci-sandbox, as this prevents
ghci from forking a thread (all computations are run in the main thread). As
noted previously R is not thread-safe.

This eliminates the "C stack usage" error messages, but there is still a
segfault when ghc-7.6.3 is used (and a non-trivial computation is done).
Using ghc-7.7 fixes this.


comment:8 Changed 7 months ago by rwbarton

  • Resolution set to invalid
  • Status changed from new to closed

Great, glad you were able to get it working!

Note: See TracTickets for help on using tickets.