[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