Hi all,

I checked out the current develop version today.

I ported a lot of code to Eigen last week and had to check out to the latest development revision in order to get the new ability to accept vectors of zero size. Now, I have a problem while debugging.

Using gdb no error appears.

But when using valgrind I obtain

Code: Select all

MatrixStorage.h:44: Eigen::ei_matrix_array<T, Size, MatrixOptions, Align>::ei_matrix_array() [with T = int, int Size = 4, int MatrixOptions = 0, bool Align = true]: Assertion `(reinterpret_cast<size_t>(array) & 0xf) == 0 && "this assertion is explained here: http://eigen.tuxfamily.org/dox/UnalignedArrayAssert.html  **** READ THIS WEB PAGE !!! ****"' failed.


The problem: I have no idea where this comes from. Valgrind replaces the new allocator internally, but should this be a problem?
Any ideas how I could track this down?

Edit: The same problem goes for Eigen 2.0.3

Ok, I probably found a workaround:

-D EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT


At least the asserts won't be thrown when using Valgrind. But I wonder what else would happen. Will just the optimization for fixed sized objects not work or may anything bad happen? Asserts usually have some reason...

here I cannot reproduce this issue using a 64 bits Linux system and valgrind 3.3.1 unless I remove some needed EIGEN_MAKE_ALIGNED_OPERATOR_NEW or aligned_allocator<>...

Indeed, if you are using a 64bits Linux system then the default malloc is likely to return aligned pointers unless you run your program with valgrind...

I use valgrind 3.3.1 on 64bit Intel, gcc 4.3.2. The app was compiled using debug mode. I switched back to Eigen 2.0.3 again. But the problem remains.

ggael wrote:Indeed, if you are using a 64bits Linux system then the default malloc is likely to return aligned pointers unless you run your program with valgrind...

I am pretty certain that I may forgot some EIGEN_MAKE_ALIGNED_OPERATOR_NEW . The only issue is: Running the app normally or in GDB won't change anything ( I can not find the origin of the problem since it does not occur), running it in valgrind goes into the assertion ( again I can not find the origin since the problem appears, but can not be tracked by Valgrind).

To me 2 questions arise:
o Is something wrong with my build?
o If not, would it be wise to modify the assert macro in Eigen, such that gdb and valgrind can both find the origin? For example, one could read from an invalid memory address right before the the assert is thrown...

I will continue analyzing this during the next days. Please give me some time to check if my build is broken...

Seb wrote:I use valgrind 3.3.1 on 64bit Intel, gcc 4.3.2. The app was compiled using debug mode.
To me 2 questions arise:
o If not, would it be wise to modify the assert macro in Eigen, such that gdb and valgrind can both find the origin? For example, one could read from an invalid memory address right before the assert is thrown...

Indeed, the problem it that's not easy to get a backtrace from an assert when running valgrind. What you suggested is one possibility. Another one is to analyze the core dump file:

ulimit -c unlimited
valgrind ..... exe
gdb exe vgcore.<pid>


Also note that you can control the alignment of valgrind's malloc: -alignment=16

Thanks for your help! Both hints worked well.

After a complete rebuild the problem still occured, though.

The origin was in a subroutine of a class which does not have any fixedsize members. Fixed size temporary objects were used inside the subroutine... hmmm.