Segfault when using browser() inside rpy2

Issue #66 resolved
Christian Hudon created an issue

Doing the following in python:

import rpy2.robjects as ro

and then executing "ls()" in the R browser prompt that opens causes a segfault. Being able to use the R browser to debug complex R code executed from Python would be really useful. This is with Python 2.5.2 and rpy2 2.1.3

Comments (14)

  1. Laurent Gautier
    • changed status to open
    • changed milestone to 2.2.0

    Yes. I can reproduce it on 2.2.0dev.

    In the meanwhile, consider breaking down your R code into rpy2 calls rather than evaluate large strings into R code.

  2. Christian Hudon reporter

    Any plans to look at it during the 2.2 release series? Or if you point me in the general direction, I could try to help.

    One way or another, it'd be really appreciated if this got fixed. as applying the workaround you gave is impossible for the use case I'm interested in. (When there's a bug in the R code I'm calling from python, it'd be really useful if I could drop a call to browser(), etc. in said R code to help debug the problem. Because of this bug, I can't do that.)

  3. Laurent Gautier

    I'd like to have it fixed, but I do not know when it will be.

    Great if you could help. The catch is: I don't know at all where the problem might be. Did you try running this with a debug build of Python and through something like gdb ?

    Are you certain that the workaround proposed is not applicable: you just have to use more Python (the only case it would not be applicable is if you are writing an R GUI of some sort).

  4. Christian Hudon reporter

    I can understand how "more Python" could work for other use cases, but I really don't see how this particular use case can be solved by using more Python. I have a sizeable amount of R code, which gets loaded into a Python server (through a call to R's "source" function). The Python server then calls various functions from that R code as a part of doing its work. All that works fine with rpy2. (To be explicit, all the R calls made through rpy2 are reasonably short R snippets.)

    Sometimes when working on the R code, I introduce/find bugs in said R code. Since the bugs in the R code happen when running inside the python server, the easiest way for me to debug these would be to add a "browser()" call to the R code in the place where I suspect the problem is, and launch a copy of the server in a terminal window. However, as soon as I try to interact with the R "browser()" prompt, the whole things dumps core.

    Right now I have separate, R-only code that allows me to reproduce and debug these problems (using "browser()", etc.). But it'd be easier if I didn't have to do that separate step of reproducing the state of the R code running under the python server using a separate R-only shim beforehand.

    I hope things are clearer now on my usecase. I don't really see how I can work around the crash using more python, as the problem happens in the R browser() prompt.

    Thanks for reading!

  5. Laurent Gautier

    Then what your use-case needs is akin to an R GUI / frontend with rpy2, in other words a tools for doing R development with rpy2, as you noted it R's internal capabilities for step-by-step execution of code ado not work properly.

    As things are, rpy2 is great for calling existing R code, supposing that this R code is working.

    Working around that with more Python means having more Python where you have a large chunk of (buggy/brittle) R code, either by splitting it (programmatically if necessary) into smaller pieces that you evaluate one after the next or by writting your own R step-by-step utility in Python (this is doable).

  6. Laurent Gautier

    It would certainly be good to fix the issue, if it can be. I son't see it as a release blocker for 2.3.0; it might have to be for one of the bugfix releases in the 2.3.x series.

  7. Laurent Gautier

    I have been suspecting that this was linked to PR#115, but never got the time to work on it. Now that Python has received a patch it should be possible to try whether this is the case..

  8. Laurent Gautier

    Testing with Python 2.7.5, it does seem that it was linked to PR#115. The Python developers fixed the problem. A good thing, the R core it still sitting on the patch I submitted that would have been the other way to solve the problem.

  9. Log in to comment