[R-sig-Debian] Taking determinant of a matrix of NAs results in intermittent memory corruption
Dirk Eddelbuettel
edd at debian.org
Thu Jan 19 00:19:28 CET 2017
On 18 January 2017 at 22:54, Ian Erickson wrote:
| Greetings; I've posted the following to R's bug tracking system (at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17210 ) and Martin Maechler requested that I post to this list as well.
| If I start R from the command line with --vanilla, then repeatedly execute the following line:
|
| det(matrix(nrow=10,ncol=10))
That is not reproducible code. While you a matrix with dimensions, you do not
have content in it. Did you mean something like
set.seed(42) # or any other seed
det(matrix(rnorm(100), nrow=10, ncol=10))
Ok now I looked at your example in the BTS. You meant
det(matrix( , nrow=10, ncol=10))
and I just don't know how meaningful that is. It is random input. Sure, R
should never die...
But just like Martin Maechler, I can run
r -e 'for(i in 1:100000) { d <- det(matrix(, 10,10)); stopifnot(identical(d, NA_real_)) }; cat("Alive\n")'
just fine on two different machines (which both happen to Ubuntu 16.04 using OpenBLAS).
| ... I eventually get a crash, with error:
|
| *** Error in `/usr/lib/R/bin/exec/R': malloc(): memory corruption: 0x0000000002399400 ***
|
| The specific address in memory that is referenced varies. The number of times I need to execute the above line before getting a crash also varies.
|
| This occurs with a wide range of matrix dimensions; 10x10 is not the only size that causes this issue.
|
| output of R.version:
| platform x86_64-pc-linux-gnu
| arch x86_64
| os linux-gnu
| system x86_64, linux-gnu
| status
| major 3
| minor 3.2
| year 2016
| month 10
| day 31
| svn rev 71607
| language R
| version.string R version 3.3.2 (2016-10-31)
| nickname Sincere Pumpkin Patch
|
| I am running Linux Mint 17.3; my CPU is an Intel Core i7-2620m (Sandy Bridge). My RAM is non-ECC. My R binary is from the CRAN Ubuntu repository at cran.cnr.berkeley.edu . (r-base and r-base-core versions 3.3.2-1trusty0 )
|
| I also see this issue running R within Emacs, as well as Rstudio.
|
| This issue may be related to https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16862 but I'm not certain.
|
| The output of La_version() for me is:
| [1] "3.5.0"
|
| The output of:
| system(paste("lsof -p", Sys.getpid(), "| grep -iE '(blas|lapack)'"))
| is:
| R 3636 <myusername> mem REG 252,0 39272 11930369 /usr/lib/R/modules/lapack.so
| R 3636 <myusername> mem REG 252,0 5882272 11933488 /usr/lib/lapack/liblapack.so.3.0
| R 3636 <myusername> mem REG 252,0 23108112 11929607 /usr/lib/openblas-base/libopenblas.so.0
| Is anyone able to reproduce?
I cannot as stated above.
Try one of the other blas implementations. On a .deb-based system, this is
just a an apt-get way. I keep forgetting whether atlas has higher priority
than openblas but you know enough to check this.
Dirk
| Thanks,
|
| --Ian
|
| _______________________________________________
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
More information about the R-SIG-Debian
mailing list