Hi,

I have being wrestling for a few days with an inexplicable unhandled exception, access violation reading location xxx
At first I didn’t suspect any relation with Eigen, and I still don’t know what’s happening but I think it involves alignment of Eigen fixed size types in my particular context, so I post in here, luckily you’ll have some clue to what’s going on.

I have trimmed down my program to have an example with the smallest piece of code that has the elements that produce this access violation reading.

Code: Select all

1.   class A
2.   {
3.   public:
4.     A(int a):m_a(a){};
5.     virtual int GetNumber(){return m_a;};
6.   private:
7.     int m_a;
8.   };
9.   
10.   void test(shared_ptr<A> r)
11.   {
12.     try
13.     {     
14.       throw std::runtime_error("Test exception");
15.     }
16.     catch(std::runtime_error &e)
17.     {
18.       cout << e.what() << endl;
19.     }
20.   
21.     int i = r->GetNumber();
22.   
23.     Eigen::Vector4f saxy;
24.     saxy << 1.0f, 0.0f, 0.0f, 0.0f;
25.   }
26.   
27.   void main()
28.   {
29.     shared_ptr<A> APtr(new A(2));
30.     test(APtr);
31.   }


I’m using Visual Studio C++ 2010 and Eigen 3.0.3. This code will run from begin to end in Debug mode, and release mode with optimizations disabled. However, in Release mode with full optimizations enabled (/Ox) it’ll produce this access violation at line 21.

If I change the Vector4f in line 23 to be Vector3f there won’t be an access violation at line 21. If I look at the assembly code I see that when I use Vector4f there is some padding added at the beginning of the function test.

If I make A::GetNumber not virtual there won’t be access violation at line 21 either.

If I remove the try catch block there won’t be an access violation at line 21.

If I look at the stack in the debugger, just after coming out of the catch block, line 19, I can see that the stack is corrupted. Typically there is some extra stack frame between main() and test().

Unfortunately, I need all these elements in my original program, and despite meaningless I think this code should run without any problems???

What’s going on???

Martin.

I think you should rather complain to Microsoft.

That said, you might try with:

EIGEN_ALIGN16 float saxy[4];
saxy[0] = 1.f;
saxy[1] = 0.f;
saxy[2] = 0.f;
saxy[3] = 0.f;

instead of an Eigen::Vector4f.

You could try to define EIGEN_DONT_ALIGN_STATICALLY before including Eigen (while keeping the Vector4f).

Thanks for your answer ggael .

I think I found the problem.
Visual Studio 2010 compiler has this compiler option /GS (Buffer Security Check)
http://msdn.microsoft.com/query/dev10.q ... URITYCHECK)

I had this option set to false, this produced the access violation. If I set this option to true, there is no access violation in the test case code neither in my original program.

According to msdn documentation “On x86, if a function uses an exception handler, the compiler injects a security cookie to protect the address of the exception handler. The cookie is checked during frame unwinding.” I think that the use of Eigen fixed size types introduces some padding in the stack and that conflicts with this security cookie.

Is this possible?

Martin.

if you try the two tests I suggested you'll probably know more about what's happening.

OK.

I see that using EIGEN_DONT_ALIGN_STATICALLY I don't get the access violation even if I have /GS set to false. However I would prefer to use the static alignment to get as fast code as possible. On the other hand, I don't know if using /GS set to true slows down much compared to having it unset.

With the other test you suggested, I see that EIGEN_ALIGN16 is equivalent to __declspec(align(16)) which I guess is Visual Studio own method to align locals. If I use __declspec(align(16)) float saxy[4]; I get the access violation again. So it seems that the problem exist independent to Eigen.

I'll post this in some Visual Studio C++ forum and see what I get.

Thanks
Martin

Ok, so at least now we're sure what's the origin of the issue.