[Rd] Terminating and restarting an embedded R instance possible?
I am developing R functions that interface with C++ code from the OpenCV
library. During development and unit testing, I embed an R instance to prepare
the environment in which the function encapsulating OpenCV code is called.
Running the unit testing suite results in starting (and later terminating) an
embedded R instance for each test. This produces a series of error messages
when Rf_initEmbeddedR is called for the second time. This error is reproduced
by running
#include Rembedded.h
int main(int argc, char **argv) {
Rf_initEmbeddedR(argc, argv);
Rf_endEmbeddedR(0);
Rf_initEmbeddedR(argc, argv);
Rf_endEmbeddedR(0);
return 0;
}
which outputs the following two lines
Error: bad target context--should NEVER happen;
please bug.report() [R_run_onexits]
a great number of times (this is on OS X 10.7 with Xcode 4.4.1, version
4.4.0.0.1.124936715 of the command line tools and R 2.15.1).
Debugging the above program indicates that the error happens in
installFunTab(). Not knowing R internals, I can only guess that state from the
first embedded instance leaks into the second instance.
Soeren Sonnenburg asked a similar question on March 5th 2009 but there was no
reply. He also mentioned a bug report
http://bugs.r-project.org/cgi-bin/R/trashcan?id=12644;user=guest;selectid=12644
but that link no longer works and bug # 12644 is not in the current database.
Can the above mentioned code be made to work?
Thank you,
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Terminating and restarting an embedded R instance possible?
On Aug 29, 2012, at 10:08 AM, Christian Sigg christ...@sigg-iten.ch wrote:
I am developing R functions that interface with C++ code from the OpenCV
library. During development and unit testing, I embed an R instance to
prepare the environment in which the function encapsulating OpenCV code is
called.
Running the unit testing suite results in starting (and later terminating) an
embedded R instance for each test. This produces a series of error messages
when Rf_initEmbeddedR is called for the second time.
To my best knowledge you cannot init R more than once in the same process.
There are many global variables that rely on being initialized by the data
segment. Supporting re-init of R would be a considerable effort as many of
those are static so there is no simple way to re-set them.
Cheers,
Simon
This error is reproduced by running
#include Rembedded.h
int main(int argc, char **argv) {
Rf_initEmbeddedR(argc, argv);
Rf_endEmbeddedR(0);
Rf_initEmbeddedR(argc, argv);
Rf_endEmbeddedR(0);
return 0;
}
which outputs the following two lines
Error: bad target context--should NEVER happen;
please bug.report() [R_run_onexits]
a great number of times (this is on OS X 10.7 with Xcode 4.4.1, version
4.4.0.0.1.124936715 of the command line tools and R 2.15.1).
Debugging the above program indicates that the error happens in
installFunTab(). Not knowing R internals, I can only guess that state from
the first embedded instance leaks into the second instance.
Soeren Sonnenburg asked a similar question on March 5th 2009 but there was no
reply. He also mentioned a bug report
http://bugs.r-project.org/cgi-bin/R/trashcan?id=12644;user=guest;selectid=12644
but that link no longer works and bug # 12644 is not in the current database.
Can the above mentioned code be made to work?
Thank you,
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stack overflow? was Re: [R] segfault in gplots::heatmap.2
I think this belongs on R-devel and I'm forwarding there.
Here's a more refined example
library(XLConnect)
load(file=ddr.Rda)
oV - function(x) {
if (is.leaf(x)) {
return(x)
}
for (j in seq_along(x)) {
b - oV(x[[j]])
}
x
}
res - oV(ddr) # segfault for me under 2.15.1
str(ddr)# segfault more reliably
'ddr' is a dendrogram produced from Andreas' original object at the
point where heatmap.2 calls 'reorder'. 'oV' is a reduced version of the
internal function in reorder.dendrogram.
Simple changes to oV above have interesting effects, e.g., removing {}
in the 'if' and 'for' mean that the segfault labelled at 2.15.1 does not
occur.
Under R-devel, valgrind complains about Java (I think this is a red
herring) and then
14604== Can't extend stack to 0x7fef03370 during signal delivery for
thread 1:
==14604== too small or bad protection modes
which likely indicates stack overflow.
gdb shows that we're several 1000's of calls down when the segfault occurs.
I think R overflows its stack, and that rJava just makes that more
likely to occur. I don't really know how to investigate a stack overflow
further.
Martin
R version 2.15.1 Patched (2012-08-26 r60438)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
sessionInfo()
R Under development (unstable) (2012-08-20 r60336)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On 08/30/2012 12:04 PM, R. Michael Weylandt wrote:
On Thu, Aug 30, 2012 at 2:30 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
Hi all,
I experience a segfault when calling gplots::heatmap.2(), but only when
certain other packages are loaded.
I am not sure for the correct place to send this bug report. Should I send
it to the package maintainers directly? If R-help is the wrong place,
please feel free to direct me to the correct one.
I am on debian (testing) linux 64 with the binary R distribution
from the repositories (version 2.15.1).
Below follows a simple reproducible example causing the segfault on my
machine.
The offending dataset is quite big, so instead of posting it here I put
it here: https://gist.github.com/3523761. Please put it into offending.txt to
make the code below working.
This is the example. Note, that without loading 'XLConnect' this works
nicely.
#+begin_src R
library(gplots)
library(XLConnect) # any of XLConnect, venneuler, xlsx case a segfault
offending - dget(offending.txt)
heatmap.2(x=offending)
#+end_src
Interestingly, I get a segfault when loading any of c(XLConnect,
venneuler, xlsx), which all depend on rJava. But loading rJava on
its own did not produce a segfault.
Hi Andreas,
Thanks for the nicely reproducible example. Unfortunately, I can't
reproduce the segfault on my Mac OS X 10.6 running R 2.15.0. I could
only test with rJava + venneuler because xlsx and XLConnect fall
victim to Mac's Java infelicities. It's something of a formality,
but are you sure you are up-to-date with your packages as well as with
R itself. Something like
update.packages(checkBuilt = TRUE)
will ensure you've got the most current release of all your packages.
(Note that I'm not sure that's the right way to do it on Debian)
Do you happen to know if this happens with other versions of R? e.g.,
2.15.0 or the not-yet-released R-devel or R-patched (maintenance
branch of 2.15.z which will become 2.15.2 eventually)
Consequently, I'd suspect that there's something going on in the
intersection of Java + R + Deb Testing, so three places you might seek
more advanced help, as this is likely deeper than the day-to-day of
this list. i) The rJava mailing list
(http://mailman.rz.uni-augsburg.de/mailman/listinfo/stats-rosuda-devel);
ii) the R-SIG-Debian list; iii) the R Devel list.
I'm not sure which one makes the most sense to try, but I'd think the
third should be of last resort, because it seems least likely to be a
problem in base-R if it requires rJava being around to reproduce. The
R-SIG-Debian list most likely has someone who can reproduce your exact
config.
Cheers,
Michael
Regards,
Andreas
__
[Rd] tcltk capability
There are quite a few packages that make use of tcltk and although - most R distributions have tcltk capability - its possible to query this via capabilities()[[tcltk]] - attempting to build a package that needs it on such an R distribution will give a message letting one know users still seem to have problems with this. There was recently an R bug report submitted that likely stemmed from the user having such a build of R and recently there was also an R help post that seemed to be related to this as well. As more and more packages add GUI capability these incidents are bound to increase. The best situation would be to arrange that every distribution of R have tcltk capability but if this is difficult to arrange then I suggest there be a message at start up similar to the existing locale message letting the user know that the R distribution they are running lacks tcltk capability. Preferably the message would be somewhat menacing so that users are encouraged to get a different distribution of R right from the start. This might reduce such problem reports somewhat. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stack overflow? was Re: [R] segfault in gplots::heatmap.2
On Aug 30, 2012, at 3:39 PM, Martin Morgan mtmor...@fhcrc.org wrote:
I think this belongs on R-devel and I'm forwarding there.
Here's a more refined example
library(XLConnect)
load(file=ddr.Rda)
oV - function(x) {
if (is.leaf(x)) {
return(x)
}
for (j in seq_along(x)) {
b - oV(x[[j]])
}
x
}
res - oV(ddr) # segfault for me under 2.15.1
str(ddr)# segfault more reliably
'ddr' is a dendrogram produced from Andreas' original object at the point
where heatmap.2 calls 'reorder'. 'oV' is a reduced version of the internal
function in reorder.dendrogram.
Simple changes to oV above have interesting effects, e.g., removing {} in the
'if' and 'for' mean that the segfault labelled at 2.15.1 does not occur.
Under R-devel, valgrind complains about Java (I think this is a red herring)
and then
14604== Can't extend stack to 0x7fef03370 during signal delivery for thread 1:
==14604== too small or bad protection modes
which likely indicates stack overflow.
gdb shows that we're several 1000's of calls down when the segfault occurs.
I think R overflows its stack, and that rJava just makes that more likely to
occur. I don't really know how to investigate a stack overflow further.
In general, the moment you load Java, stack checking is disabled, because that
turns the R process into a multi-threaded application so the stack is no longer
guaranteed at a fixed location. Guarding the stack is messy enough without
threads, but it becomes close to impossible with threads.
If you have stack checking enabled, it gets caught:
str(ddr)# segfault more reliably
[...]
|--leaf 124
| | || |
`--Error: C stack usage is too close to the limit
Cheers,
Simon
Martin
R version 2.15.1 Patched (2012-08-26 r60438)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
sessionInfo()
R Under development (unstable) (2012-08-20 r60336)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On 08/30/2012 12:04 PM, R. Michael Weylandt wrote:
On Thu, Aug 30, 2012 at 2:30 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
Hi all,
I experience a segfault when calling gplots::heatmap.2(), but only when
certain other packages are loaded.
I am not sure for the correct place to send this bug report. Should I send
it to the package maintainers directly? If R-help is the wrong place,
please feel free to direct me to the correct one.
I am on debian (testing) linux 64 with the binary R distribution
from the repositories (version 2.15.1).
Below follows a simple reproducible example causing the segfault on my
machine.
The offending dataset is quite big, so instead of posting it here I put
it here: https://gist.github.com/3523761. Please put it into offending.txt
to
make the code below working.
This is the example. Note, that without loading 'XLConnect' this works
nicely.
#+begin_src R
library(gplots)
library(XLConnect) # any of XLConnect, venneuler, xlsx case a segfault
offending - dget(offending.txt)
heatmap.2(x=offending)
#+end_src
Interestingly, I get a segfault when loading any of c(XLConnect,
venneuler, xlsx), which all depend on rJava. But loading rJava on
its own did not produce a segfault.
Hi Andreas,
Thanks for the nicely reproducible example. Unfortunately, I can't
reproduce the segfault on my Mac OS X 10.6 running R 2.15.0. I could
only test with rJava + venneuler because xlsx and XLConnect fall
victim to Mac's Java
