Bug 15332 - qr.solve call crashes R
qr.solve call crashes R
Status: CLOSED FIXED
Product: R
Classification: Unclassified
Component: Low-level
R 3.0.0
Other All
: P5 normal
Assigned To: R-core
: 15367 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-03 06:37 UTC by Anton Korobeynikov
Modified: 2013-06-29 21:26 UTC (History)
2 users (show)

See Also:


Attachments
Test data (857.93 KB, application/octet-stream)
2013-06-03 06:41 UTC, Anton Korobeynikov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Korobeynikov 2013-06-03 06:37:57 UTC
Consider the attached funqr.rda file.

Steps to reproduce:

env <- new.env()
load("funqr.rda", envir = env)
qr.solve(env$predictors, as.complex(env$F)) # works as expected
qr.solve(env$predictors, env$F) # crashes

Running R --debug=valgrind yields:

==65052== Invalid read of size 8
==65052==    at 0x15E96B9: ATL_zgemvC_a1_x1_b1_y1 (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==65052==    by 0x15E5264: ATL_zgemv (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==65052==    by 0x15EB781: cblas_zgemv (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==65052==    by 0x139B950: ZGEMV (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==65052==    by 0x9D4C74D: zlarf_ (in /opt/local/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libRlapack.dylib)
==65052==    by 0x104112497: ???
==65052==    by 0x9D8A47F: bswpiv.35032 (in /opt/local/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libRlapack.dylib)
==65052==    by 0x9D8A4B7: bswpiv.35032 (in /opt/local/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libRlapack.dylib)
==65052==    by 0x100669DF7: ???
==65052==    by 0x9D8A47F: bswpiv.35032 (in /opt/local/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libRlapack.dylib)
==65052==    by 0x100000012: ??? (in /opt/local/Library/Frameworks/R.framework/Resources/bin/exec/R)
==65052==    by 0x102BD83A7: ???
==65052==  Address 0x103a22b50 is 8 bytes after a block of size 277,784 alloc'd
==65052==    at 0x4756: malloc (vg_replace_malloc.c:274)
==65052==    by 0xEFA6B: Rf_allocVector (in /opt/local/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libR.dylib)
==65052==    by 0x1FFFFFFFF: ???
==65052==    by 0x1: ???

So, it looks like R allocates too small memory for some vector. I have not dug more inside, but probably it allocates the space for real object, but treat the memory as complex.

This reproduces at least in Windows and MacOS. The input data needs to be sufficiently enough to overwrite some memory locations in order to crash R.
Comment 1 Anton Korobeynikov 2013-06-03 06:41:47 UTC
Created attachment 1452 [details]
Test data
Comment 2 Duncan Murdoch 2013-06-08 19:03:14 UTC
Looks like a simple typo in the complex-handling code.  Fixed in R-devel, soon in R-patched.
Comment 3 Duncan Murdoch 2013-06-29 21:26:33 UTC
*** Bug 15367 has been marked as a duplicate of this bug. ***