You can also read the process map table in /proc/<pid>/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 & badAddr < endAddr)
to see where the bad address is. The "<BSS>" lines are uninitialized memory
required by a shared object (or executable), I believe the object mentioned
in the previous line. A shared object may have a _fini procedure that refers to
an address in a shared object that got unloaded (_fini might call C++
destructors).
Here is some code to read the map table for the current process. I did a quick
check of the code on both 32- and 64-bit Linux. My 32-bit machine does not
have a recent version of R on it so there is some wierd code to work around
that.
readProcessMaps <- function()
{
# Read /proc/$CWD/maps into a data.frame. This shows which
# memory addresses are associated with which shared objects
# at the current time.
#
# there are some hacks to make this work in R-2.10.1 (2009), the only
# version I have compiled for 32-bit Linux.
# * as.hexmode() only accepted a scalar
# * read.table() did not have a text= argument
txt <- readLines(file.path("/proc", Sys.getpid(), "maps"))
nFields <- count.fields(textConnection(txt))
txt[nFields == 5] <- paste(txt[nFields == 5], "<BSS>")
txt <- sub("-", " ", txt)
colNames <- c("startAddr", "endAddr", "perms", "offset", "dev", "inode",
"pathname")
# retval <- read.table(text=txt, col.names=colNames, colClasses="character")
retval <- read.table(textConnection(txt), col.names=colNames,
colClasses="character")
hex64StringToDouble <- function(s) {
# as.hexmode only works up to 2^31-1, so we
# convert 64-bit address nibble by nibble into a double.
n <- nchar(s)
acc <- numeric(length(s))
for(shift in (0:3)*16) {
# nibble <- as.integer(as.hexmode(substring(s, n-3, n)))
nibble <- as.integer(sapply(substring(s, n-3, n), as.hexmode))
n <- n - 4
acc <- acc + 2^shift * nibble
}
acc
}
retval[["startAddr"]] <- hex64StringToDouble(retval[["startAddr"]])
retval[["endAddr"]] <- hex64StringToDouble(retval[["endAddr"]])
retval
}
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
> -----Original Message-----
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
> Behalf
> Of Rory Winston
> Sent: Thursday, June 13, 2013 3:56 AM
> To: r-devel@r-project.org
> Subject: Re: [Rd] load/unload segfault puzzle
>
> 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 finalizers....not
> pretty I know, but
> may be the quickest approach to quickly identify whats failing...
> Cheers
> -- Rory
>
>
> >
>
> > Yes, thanks -- Bill Dunlap already suggested this. Your and Bill's
> > warning about how slow gctorture makes things is correct -- I gave up
> > after running for 3.5 hours when it had gotten only partway through
> > loading the Matrix package; I will have to find a machine with a decent
> > cooling system (i.e. not my laptop) where I can replicate the error.
> > I've just re-run the regular valgrind, with a fresh build right after
> > an SVN update. I got exactly the same results as above. We're
> > certainly *not* calling reg.finalizer() anywhere in our package, and I
> > don't think Rcpp or RcppEigen or minqa do ... there looks to be some
> > kind of default finalization done on the reference class objects (based
> > on running 'strings' on the object files ...
> > I tried gdb'ing in and setting a breakpoint at memory.c:1357, but this
> > breakpoint gets hit a lot, and I'm sort of stabbing in the dark at this
> > point.
> >
> > Ben Bolker
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > R-devel@r-project.org mailing list DIGESTED
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> > End of R-devel Digest, Vol 124, Issue 12
> > ****************************************
>
> ______________________________________________
> 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
