amazon linux: longjmp causes uninitialized stack frame

Issue #209 closed
Jake Swanson created an issue

I've got a python beanstalk app successfully installing R, R-devel and rpy2 so that we can use python to call R code. I've tested out simple R code and can, for example, build a simple string in R and output it in the browser. However, I am getting this error when I go to source an R file into rpy2 (the rinterface/_rinterface.so line makes me think it's an rpy2 issue):

[Tue Jul 01 14:48:23.136566 2014] [core:error] [pid 8004] [client x.x.x.x:60044] Script timed out before returning headers: runserver.py
*** longjmp causes uninitialized stack frame ***: (wsgi:wsgi)     terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f2cfba1ef07]
/lib64/libc.so.6(+0xf7e2d)[0x7f2cfba1ee2d]
/lib64/libc.so.6(__longjmp_chk+0x29)[0x7f2cfba1ed89]
/usr/lib64/R/lib/libR.so(+0xb309d)[0x7f2cde94309d]
/usr/lib64/R/lib/libR.so(+0xb1db2)[0x7f2cde941db2]
/usr/lib64/R/lib/libR.so(Rf_errorcall+0x3b1)[0x7f2cde942b01]
/usr/lib64/R/lib/libR.so(Rf_error+0x10c)[0x7f2cde942e8c]
/opt/python/run/venv/lib/python2.7/site-packages/rpy2/rinterface/_rinterface.so(+0x90c2)[0x7f2cded9c0c2]
/lib64/libpthread.so.0(+0xf5b0)[0x7f2cfbedf5b0]
/lib64/libc.so.6(kill+0x7)[0x7f2cfb95b237]
/etc/httpd/modules/mod_wsgi27.so(+0xdf5d)[0x7f2cf0f64f5d]
/lib64/libpthread.so.0(+0x7f18)[0x7f2cfbed7f18]
/lib64/libc.so.6(clone+0x6d)[0x7f2cfba09e0d]
=

Comments (6)

  1. Jake Swanson reporter

    for anyone wondering what I ended up doing, I switched to just using python's subprocess package to call R files directly, using the 'Rscript' terminal command:

    subprocess.checkout_output(['Rscript', 'someFile.R', input1, input2])
    
  2. Laurent Gautier

    The line rpy2/_rinterface.so in the backtrace is there because you are using rpy2. The cause of the problem is not necessarily there.

    With a lot of guessing, I am suspecting that your R code is failing with an error (Rf_error() is called in a particularly challenging situation, with multithreading involved. While R will crash as soon as multithreading is involved, rpy2 is implementing a simple protection (lock) that will trade the segfault for an exception. You might have found a way to slip pass it.

    Without a code example to reproduce the issue, or even the version of the software involved, it is relatively hard to find the likely cause of the issue.

    In the meantime, just don't use threads.

  3. Laurent Gautier

    rpy2 should not segfault, but I can't do much without knowing more about how this is triggered (or the versions of R, rpy2, Python used).

  4. Laurent Gautier

    Closed for now. Reopen if the issue comes back and there is a suspected way to reproduce it (on my end).

  5. Log in to comment