# rpy2 crashes upon import with R 3.0.2

Issue #150 resolved
Luca Beltrame created an issue

As described on the ML, rpy2 crashes upon import.

The initial suspicion is that the following reported change in R-3.0.2 is linked to the issue:

 \item \code{eval} and \code{applyClosure} are now protected
against package code supplying an invalid \code{rho}.


For now reverting to R 3.0.1 is the only possible option.

Same on Windows.

• edited description

[minor edits]

The change reported in the R changelog for 3.0.2 is indeed triggering the issue. That's revision 63421 in R's SVN, file src/main/eval.c :

 63421     ripley
63421     ripley     if (!rho)
63421     ripley       error("'rho' cannot be C NULL: detected in C-level eval");
63421     ripley     if (!isEnvironment(rho))
63421     ripley       error("'rho' must be an environment not %s: detected in C-level eval",
63421     ripley             type2char(TYPEOF(rho)));
63421     ripley


R is trying to bubble up the error and print the message while Python (thinks it) is in charge. It does not end up well.

Now this latest change is R is uncovering a rather intriguing behavior with R. In rpy2 there is the following code (newPySexpObject() in _rinterface.c):

  if (TYPEOF(sexp) == PROMSXP) {
PROTECT(env_R = PRENV(sexp));
PROTECT(sexp_ok = eval(sexp, env_R));
#ifdef RPY_DEBUG_PROMISE
printf("  evaluating promise %p into %p.\n", sexp, sexp_ok);
#endif
UNPROTECT(2);
}


It is checking whether an R object in a "promise", and if so evaluates (possible performance hit, but there are already enough hoops to jump through to interface with R as it is - promises are evaluated when the object must be exposed to Python).

This call to R's eval() is creating a crash... when called a second time (example below).

import rpy2.rinterface as ri
ri.initr()
# this is fine, the promise is evaluated
ri.baseenv['pi']
# this is no longer fine (?!), env_R is no longer an environment
ri.baseenv['pi']


Puzzling.

Could people try if 2059:e9b8d9b473fe is fixing the issue for everyone (this is in the branch version_2.4.x) ?

If it does, I can backport the fix to the 2.3.x series and release quickly an rpy2-2.3.8.

Seems to work. I tried the changes with 2.3.x and the crash is gone. Tested on win-amd64-py3.3.

1. Backported to branch_2.3.x, and rpy2-2.3.8 was just released.