New user self-registration is currently disabled. Please email eigen-core-team @ if you need an account.
Bug 647 - Memory access violation in SparseQR
Memory access violation in SparseQR
Product: Eigen
Classification: Unclassified
Component: Sparse
x86 - 64-bit Windows
: High major
Assigned To: Nobody
Depends on:
  Show dependency treegraph
Reported: 2013-08-19 12:54 UTC by Pavel
Modified: 2013-08-26 09:11 UTC (History)
0 users

Traceback to bounds errors (36.41 KB, text/plain)
2013-08-19 12:54 UTC, Pavel
no flags Details

Description Pavel 2013-08-19 12:54:46 UTC
Created attachment 376 [details]
Traceback to bounds errors

Here is simple code to reproduce the bug: 

#include <mpreal.h>
#include <MPRealEigenSupport.h>
#include <Eigen/SparseQR>

using namespace Eigen;

typedef mpfr::mpreal /*double*/ Scalar;
typedef Eigen::DenseIndex Index; // int - the same problem

typedef Eigen::SparseMatrix< Scalar, Eigen::ColMajor, Index> SparseMatrixType;

int _tmain(int argc, _TCHAR* argv[])
    // Simple test matrix
    SparseMatrixType A(7,5);

    size_t x[15] = { 1, 3,5,0, 1, 1,4, 5, 6,0,2,4, 2,3,6};
    size_t y[15] = { 0, 0,0,1, 1, 2,2, 2, 2,3,3,3, 4,4,4};
    Scalar v[15] = { 4,-2,1,2,-1,-1,4,10,10,1,3,2,-6,2,1};

    for (size_t i = 0; i < 15; i++) A.insert(x[i],y[i]) = v[i];


    SparseQR< SparseMatrixType, NaturalOrdering<Index> > solver;


After "solver.compute(A);" program causes segfault. 

Intel C++ compiler in debug mode detects 15 out-of-bounds read/write errors (see attached file for traceback).

1. Bug is reproducible using MSVC 2010 and Intel C++ compiler (on Windows) in x64 builds (didn't check 32-bit yet).
2. Intel compiler detects same out-of-bounds errors for 'double' and 'mpreal'.
3. Problems are independent of ordering methods (second template argument in SparseQR).

As far as I see, all errors are traced back to line 331 in SparseQR.h when we try to compute  "m_pmat.col(j).norm()" and subsequent specializations.
Comment 1 Pavel 2013-08-19 13:00:40 UTC
One more note:
4. If we change Index to be "int", which is 32-bit - bug still persists.

Note You need to log in before you can comment on or make changes to this bug.