[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
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 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
>
> 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
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
__
r-h...@r-project.org ma
[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 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
>> 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
>> repr
Re: [Rd] non portable filenames
I think Kasper got a valid point and I'd second the idea of make R
accept tildes in filenames throughout. AFAIK, this is also compatible
with most file systems, cf. http://en.wikipedia.org/wiki/Filename
However, there will be some potentially ambiguous cases. For
instance, what if you have a directory named "~" in the current
directory. If you then refer to "~" from within the current
directory, should that have high priority than the current user's home
directory? I don't think so, because otherwise it would not be
possible to address that home directory. This is also how R does it
now as the following example illustrates:
# Create a local "~" directory
> dir.create("./~")
# Write a file to that directory
> cat(file="./~/foo.txt", "Hello world!\n");
# Read it
> readLines("./~/foo.txt")
[1] "Hello world!"
# Try to read it without the explicit "./" path.
> readLines("~/foo.txt")
Error in file(con, "r") : cannot open the connection
The latter will try to read foo.txt in the user's home directory.
/Henrik
On Mon, Aug 27, 2012 at 6:58 AM, Kasper Daniel Hansen
wrote:
> I am including an external piece of software in an R package. This
> software ships with its own configure script generated by
> autoconf/automake, and this script is being run as part of the package
> configure script.
>
> The package contains a file
> m4/lt~obsolete.m4
> which - as far as I can see - is a standard file from the
> autoconf/automake/m4 suite of programs. A warning is generated with R
> CMD check about this filename being non-portable. Presumably because
> of the "~" in the file name. The users is referred to the 'Package
> structure' part of R-exts.
>
> Reading the manual, I do not see "~" listed in the beginning of the
> paragraph where non-allowed characters are described. Quoting:
>
> "To ensure that file names are valid across file systems and supported
> operating system platforms, the ASCII control characters as well as
> the characters ‘"’, ‘*’, ‘:’, ‘/’, ‘<’, ‘>’, ‘?’, ‘\’, and ‘|’ are not
> allowed in file names. In addition, files with names ‘con’, ‘prn’,
> ‘aux’, ‘clock$’, ‘nul’, ‘com1’ to ‘com9’, and ‘lpt1’ to ‘lpt9’ after
> conversion to lower case and stripping possible “extensions” (e.g.,
> ‘lpt5.foo.bar’), are disallowed. Also, file names in the same
> directory must not differ only by case (see the previous paragraph).
> In addition, the basenames of ‘.Rd’ files may be used in URLs and so
> must be ASCII and not contain %."
>
> However, "~" is also not part of the next sentence where allowed
> characters are listed. Quoting
>
> "For maximal portability filenames should only contain only ASCII
> characters not excluded already (that is A-Za-z0-9._!#$%&+,;=@^(){}'[]
> — we exclude space as many utilities do not accept spaces in file
> paths): non-English alphabetic characters cannot be guaranteed to be
> supported in all locales. It would be good practice to avoid the shell
> metacharacters (){}'[]$."
>
> To me it looks a bit like this paragraph is not self-consistent, since
> "~" is not listed as one of the characters already excluded.
>
> Now, I don't really know if "~" is portable. But I assume that the
> autoconf/automake/m4 people has thought a bit about this. And I don't
> really want to rename the file in question, as it is part of a lengthy
> configure script. So I guess my question is, is R CMD check correct
> in flagging the file? And what is recommended? I am tempted to
> ignore this warning, but I know warnings sometimes become errors.
>
> I assume other people might be in the same situation, since the
> filename originates from autoconf/automake/m4.
>
> Kasper
>
> __
> 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
