[Rcpp-devel] Memory error when using Dimension
Douglas Bates
bates at stat.wisc.edu
Tue Jun 5 20:19:21 CEST 2012
Some time ago I mentioned memory errors that seemed to be related the
the Rcpp::Dimension class but I couldn't pin them down. I have a more
detailed, although not necessarily reproducible, example now.
In the merPredD::condVar method defined in the lme4/src/predModule.cpp
source file there is the line
Rcpp::NumericVector ansi(Rcpp::Dimension(ncti, ncti, nli));
When that method is eventually invoked from a version of lme4 compiled
with -ltcmalloc for R-2.15.0 (Ubuntu Version: 2.15.0-1precise0)
tcmalloc reports an attempt to free an invalid pointer. The gdb
traceback is
> print(dotplot(ranef(fm1, postVar = TRUE), strip = FALSE)[[1]])
src/tcmalloc.cc:390] Attempt to free invalid pointer: 0x53d75d0
Program received signal SIGABRT, Aborted.
0x00007ffff726f445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0 0x00007ffff726f445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7272bab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff0e507fb in ?? () from /usr/lib/libtcmalloc.so.0
#3 0x00007ffff0e50b04 in TCMalloc_CrashReporter::PrintfAndDie(char
const*, ...) () from /usr/lib/libtcmalloc.so.0
#4 0x00007ffff0e45840 in ?? () from /usr/lib/libtcmalloc.so.0
#5 0x00007ffff0e64191 in tc_delete () from /usr/lib/libtcmalloc.so.0
#6 0x00007ffff07fcde6 in deallocate (__p=<optimized out>,
this=<optimized out>) at /usr/include/c++/4.6/ext/new_allocator.h:98
#7 _M_deallocate (__p=<optimized out>, this=<optimized out>,
__n=<optimized out>) at /usr/include/c++/4.6/bits/stl_vector.h:156
#8 ~_Vector_base (this=<optimized out>, __in_chrg=<optimized out>) at
/usr/include/c++/4.6/bits/stl_vector.h:142
#9 ~vector (this=0x7fffffff9620, __in_chrg=<optimized out>) at
/usr/include/c++/4.6/bits/stl_vector.h:351
#10 ~Dimension (this=0x7fffffff9620, __in_chrg=<optimized out>) at
/home/bates/R/x86_64-unknown-linux-gnu-library/2.15/Rcpp/include/Rcpp/Dimension.h:29
#11 lme4::merPredD::condVar (this=0x5720000, rho=...) at predModule.cpp:105
#12 0x00007ffff07dc608 in merPredDcondVar (ptr=0x474c8c0,
rho=<optimized out>) at external.cpp:617
...
(gdb) up 10
#10 ~Dimension (this=0x7fffffff9620, __in_chrg=<optimized out>) at
/home/bates/R/x86_64-unknown-linux-gnu-library/2.15/Rcpp/include/Rcpp/Dimension.h:29
29 class Dimension {
(gdb) p dims
$1 = {<std::_Vector_base<int, std::allocator<int> >> = {_M_impl =
{<std::allocator<int>> = {<__gnu_cxx::new_allocator<int>> = {<No data
fields>}, <No data fields>}, _M_start = 0x53d75d0,
_M_finish = 0x53d75dc, _M_end_of_storage = 0x53d75dc}}, <No data fields>}
so the address in question is the _M_start of the dims
std::vector<int> private member of the Rcpp::Dimension instance. The
length of 12 bytes (difference between _M_finish and _M_start) is what
would be expected for a std::vector<int> of length 3.
Those memory locations have the values we would expect
(gdb) up
#11 lme4::merPredD::condVar (this=0x5720000, rho=...) at predModule.cpp:105
105 Rcpp::NumericVector ansi(Rcpp::Dimension(ncti, ncti, nli));
(gdb) p ncti
$2 = 1
(gdb) p nli
$3 = 6
(gdb) down
#10 ~Dimension (this=0x7fffffff9620, __in_chrg=<optimized out>) at
/home/bates/R/x86_64-unknown-linux-gnu-library/2.15/Rcpp/include/Rcpp/Dimension.h:29
29 class Dimension {
(gdb) p {int}0x53d75d0
$4 = 1
(gdb) p {int}0x53d75d4
$5 = 1
(gdb) p {int}0x53d75d8
$6 = 6
To me it looks as if the pointer to the contents is being passed as
the pointer to a malloc'd chunk, which has a header describing the
size of the chunk. This may be the common approach - I don't know
enough about the innards of malloc and free to tell.
Anyway, I can't see anything suspicious in the code in
Rcpp/src/Dimension.cpp. For the time being I am going to fall back on
the standard malloc/free
Well, actually I did another thing which is to replace the line 105 by
Rcpp::NumericVector ansi(ncti * ncti * nli);
ansi.attr("dim") = Rcpp::IntegerVector::create(ncti, ncti, nli);
and now things are fine. Still don't know what the problem was though.
More information about the Rcpp-devel
mailing list