Bill
Hadn't thought of that - great idea. I wonder if it would be possible to run R
under gdb and trap the segfault - this should give the invalid address in the
backtrace - and then grep the process map for that address?
Cheers
-- Rory
Sent from my iPhone
On 14 Jun 2013, at 00:34, William D
I suggest adding this to R_HOME/doc/KEYWORDS.db:
Programming|testing: Software testing
and add a corresponding entry in R_HOME/doc/KEYWORDS.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailma
Freetype 2.4.12 was released in early May. Just so that we are clear that this
is a freetype bug which affects R's use of Cairo (among other things). So there
are updated bundles, and also bundles for Mac OS X as well, for both a patched
2.4.11 and 2.4.12 proper. The accompanying *.txt has a lis
You can also read the process map table in /proc//maps to see which
shared object is associated with the illegal address that valgrind identified.
Read the map table after each load or unload of a *.so with
map <- readProcessMaps()
and use something like
subset(map, startAddr <= badAddr & bad
Ben
Have you compiled R form source yourself? If so, I would be tempted to mark up
memory. c with some debug log statements - especially around line 1357, and
possibly inside the finalizers function as it attempts to run the C
finalizersnot pretty I know, but may be the quickest approach to
