My whole code is here: https://github.com/alkamid/QCLD/blob/ma ... ce/QCL.cpp

Line #591 reads:

Code: Select all

   PHI_VECTOR = -(z_step)*(z_step)*POISSON_M.lu().solve(DENSITY_VECTOR);

It works fine on Linux, compiled with g++ 4.7.2. However, on Windows (mingw gcc 4.7.1), I get an error on that line. The debugger says:

Code: Select all

#0 ??   unpackRhs (b=0x2a8bbf0, rhs=0x29b1bb00, n=41808896, this=<optimized out>) (C:\Users\ak763\Documents\GitHub\QCLD\source\QCL.cpp:1384)
#1 ??   Eigen::internal::gebp_kernel<double, double, int, 2, 2, false, false>::operator() (res=res@entry=0x2a80030, resStride=resStride@entry=751, blockA=blockA@entry=0x0, blockB=blockB@entry=0x0, rows=rows@entry=18939904, depth=depth@entry=20904448, cols=cols@entry=44612592, alpha=-1, strideA=strideA@entry=20904448, strideB=strideB@entry=8, offsetB=offsetB@entry=43719600, unpackedB=unpackedB@entry=0x2a8bbf0, this=<optimized out>, offsetA=0) (C:/Users/ak763/Documents/GitHub/QCLD/source/../Eigen/src/Core/products/GeneralBlockPanelKernel.h:552)
#2 004393CA   Eigen::internal::triangular_solve_matrix<double, int, 1, 5, false, 0, 0>::run(size=72, otherSize=4420255, _tri=0x8, triStride=72, _other=0x2a80030, otherStride=751, blocking=...) (C:/Users/ak763/Documents/GitHub/QCLD/source/../Eigen/src/Core/products/TriangularSolverMatrix.h:153)
(...)


Then, a window appears with "QCLD.exe has stopped working. Windows is checking for a solution to the problem", i.e. I get a segmentation fault.
Any idea what may cause this error?

I guess this is a problem of non aligned stack. Could you try with the devel branch, I fixed a similar issue yesterday.

Same thing happens:

Code: Select all

#0 ??   unpackRhs (b=0x28dbbf0, rhs=0x2801bb00, n=5895168, this=<optimized out>) (C:\Users\ak763\Documents\GitHub\QCLD\source\QCL.cpp:1382)
#1 ??   Eigen::internal::gebp_kernel<double, double, int, 2, 2, false, false>::operator() (res=res@entry=0x28d0030, resStride=resStride@entry=751, blockA=blockA@entry=0x0, blockB=blockB@entry=0x0, rows=rows@entry=262148, depth=depth@entry=2947584, cols=cols@entry=42843120, alpha=-1, strideA=strideA@entry=2947584, strideB=strideB@entry=8, offsetB=offsetB@entry=41950128, unpackedB=unpackedB@entry=0x28dbbf0, this=<optimized out>, offsetA=0) (C:/Users/ak763/Documents/GitHub/QCLD/source/../Eigen/src/Core/products/GeneralBlockPanelKernel.h:559)
#2 00439982   Eigen::internal::triangular_solve_matrix<double, int, 1, 5, false, 0, 0>::run(size=72, otherSize=4423911, _tri=0x8, triStride=72, _other=0x28d0030, otherStride=751, blocking=...) (C:/Users/ak763/Documents/GitHub/QCLD/source/../Eigen/src/Core/products/TriangularSolverMatrix.h:160)
#3 0028F388   ?? () (??:??)


hm, it seems your matrix is pretty big: 72 x 4420255. Is it the expected dimension? Does it fail with a smaller problem?

ggael wrote:hm, it seems your matrix is pretty big: 72 x 4420255. Is it the expected dimension? Does it fail with a smaller problem?

That's strange. POISSON_M.size() = 751x751 = 564001 and DENSITY_VECTOR.size() = 751.

Yes, there must be some memory errors. You could first check that the linux version is not hiding memory problem using valgrind, and then try with a similar tool on the windows version (http://stackoverflow.com/questions/4134 ... or-windows)

Valgrind says:

Code: Select all

==9784==
==9784== HEAP SUMMARY:
==9784==     in use at exit: 0 bytes in 0 blocks
==9784==   total heap usage: 16,037 allocs, 16,037 frees, 30,809,180,785 bytes allocated
==9784==
==9784== All heap blocks were freed -- no leaks are possible
==9784==
==9784== For counts of detected and suppressed errors, rerun with: -v
==9784== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)


Is it possible that on Windows there are memory leaks nevertheless?

I'm not thinking about memory leaks, but not initialized variable or out-of-bound access and the likes because the matrix dimensions seems to go wrong...

Is there a way I could check this with valgrind?

yes, valgrind does this kind of checks, however, the memory issue might only show up on windows so you need a similar tool as valgrind for windows (see previous link).

I tried another version of mingw32-gcc (4.8.1) and it works fine now. Possibly a bug in the old compiler?