[Rcpp-devel] RcppEigen: .conservativeResize() on 32-bit Windows

Dirk Eddelbuettel edd at debian.org
Wed Apr 4 17:59:19 CEST 2012


On 4 April 2012 at 15:53, Andreas Alfons wrote:
| Dear Rcpp devs, dear list,
| 
| First of all, thanks a lot for all the effort you put into the Rcpp packages!
| 
| I wrote a package using RcppEigen, where in one function I need to
| iteratively add and remove vector elements a lot. On 32-bit Windows 7,
| the program crashes the R session. It works fine on Ubuntu Oneiric, OS
| X Lion (32-bit and 64-bit) and 64-bit Windows 7.
| 
| I could narrow the problem down to strange behavior of the function
| .conservativeResize(), which I use a lot to resize the vectors. Here
| is a minimal example:
| 
| 
| library("inline")
| test <- cxxfunction(signature(R_p = "integer", R_max = "integer"),
|     'int p = as<int>(R_p), max = as<int>(R_max);
|         // initialize vector with sequence from 0 to p-1
|         Eigen::VectorXi x(p);
|         for(int j = 0; j < p; j++) {
|             x(j) = j;
|         }
|         // iteratively remove vector elements
|         int k = 0;
|         while(k < max) {
|             p--;
|             x.segment(0, p) = x.tail(p).eval();  // move last elements up
|             x.conservativeResize(p);              // resize vector
|             k++;
|         }
|         return wrap(x);',
|     plugin = "RcppEigen")
| 
| test(10, 3)
| 
| 
| On 32-bit Windows 7, I get the output
| [1] 55862592        2        3        4        5        6        7
| 
| The example is not reproducible all the time, sometimes I get the correct output
| [1] 3 4 5 6 7 8 9
| 
| But restarting the R session once or twice worked for me to get some
| incorrect output (not always the same as above). Could the problem be
| that the R garbage collector deletes some memory there for some
| reason? A standalone C++ version of the example (without going through
| R) seems to work fine on 32-bit Windows 7.
| 
| Resizing matrices seems to work correctly on 32-bit Windows 7, too, so
| maybe I this will provide a workaround for now.
| 
| Thanks in advance for your help and sorry for the quite long mail!

Thanks for the report.  Doug has pointed out a few times that the
'thread-safe malloc' (libtcmalloc) from the Google Performance Tools manages
to tickle some memory bug too, coupled with an R-dev build with proper
flags.  Unfortunately I was unable to reproduce that on my box.  If this
leads to anything we may well get a chance to chase this down.

Dirk

| 
| - Andreas
| 
| 
| -- 
| Andreas Alfons
| Faculty of Business and Economics, KU Leuven
| www.econ.kuleuven.be/andreas.alfons/public/
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-- 
R/Finance 2012 Conference on May 11 and 12, 2012 at UIC in Chicago, IL
See agenda, registration details and more at http://www.RinFinance.com


More information about the Rcpp-devel mailing list