SEH exception with code 0xc0000005 thrown in the test body

Question

I am writing a test using GoogleTest for the following class and I am getting the above error.

class Base
{
    // Other Functions;

    CSig objSig[50];
}

The Class CSig is as follows:

class CSig
{
    //... constructor, destructor(empty) and some functions
    CMod *objMod;
    CDemod *objDemod;
}

CSig :: CSig
{
    bIsInitialised = false;

    for (int i=0; i<MAX_NUM; i++)
    {
        PStrokePrev[i] = 0.0;
    }
}

However, when I discard CSig objSig[50], the tests run fine.

What can I do to solve this issue? Also, I need to have CSig objSig[50] in the Base class.

`0xc0000005` is access violation. You need to show us more code (`CSig`'s constructor/destructor possibly). — avakar, Oct 31 '12 at 12:13
What is `PStrokePrev` and does it have space for `MAX_NUM` doubles? — Blastfurnace, Oct 31 '12 at 14:30
Thanks. `PStrokePrev` is an array of type double and it does have space for `MAX_NUM`. — chintan s, Oct 31 '12 at 14:38
Were is `PStrokePrev` declared? Is it dynamically allocated and has it been created before the `CSig` constructor is called? Why doesn't your constructor initialize `objMod` or `objDemod`? The source of the error isn't obvious from the small code snippet you've posted. I'm just pointing out a possible array overrun and uninitialized pointers that could cause the fault. — Blastfurnace, Oct 31 '12 at 15:00
This just started happening to me with the latest VS2019, c++17. My colleague found [this](https://developercommunity.visualstudio.com/content/problem/847490/msvc-codegen-error-vector-reverse-iterator-x64-c17.html) issue, which is a pending fix at the time of this comment. — Joel, Dec 11 '19 at 16:01

score 44 · Answer 1 · answered Oct 31 '12 at 12:32

44

A SEH (Structured Exception Handling) exception is not a C++-exception that can be handled using c++-language constructs (try-catch) but it is raised from windows itself and points to some fundamental flaw. SEH-exceptions are very annoying because they do not cause normal stack unwinding which can lead to unclosed files or not-unlocked mutexes that should normally cleared by the destructors of the owning object. I have encountered SEH-exceptions when accessing memory that does not belong to the current process so I recommend looking at memory-related instructions in the constructor and destructor of CSig. You can read about SEH, for instance, here

answered Oct 31 '12 at 12:32

MadScientist

3,390
15
19

Thanks for your reply. Will it help if I change `CSig objSig[50]` to `CSig *objSig` and initialise it in the constructor. Thanks. – chintan s Oct 31 '12 at 14:02
Do you have to use c-style-arrays? If you can, I recommend using STL-containers (esp. std::vector, std::array). In debug mode all accesses are checked which could help you find your bug. – MadScientist Oct 31 '12 at 16:31
Thanks for your reply. I do not mind using STL-containers. Can you please tell me what are the advantages? Cheers. – chintan s Oct 31 '12 at 17:23
the advantage is that if you do `std::vector objSig(50)`, the elements will be default constructed (or you can emplace the constructed object of your choice). The takeaway is that you should be initializing all the members of this array to actual objects – yano Dec 01 '17 at 18:38

score 17 · Answer 2 · answered Mar 17 '15 at 13:33

17

The way I just found the problem was that in Visual Studio I went to Debug->Exceptions, and checked everything in the first column. Then run/debug your unit tests, and it will throw an exception on the line that the problem is at. That's where you need to debug/fix it.

answered Mar 17 '15 at 13:33

Michele

3,617
12
47
81

8

For visual studio 2015: Debug->Windows->Exception Settings – chtenb Feb 08 '16 at 11:32

score 11 · Answer 3 · answered Feb 26 '15 at 22:54

I ran into this very problem using GoogleTest with Visual Studio 2010. Our setup involves creating a library for the GoogleTest Frameworks, which is then linked against our individual Unit Tests. I recently updated the Frameworks support and recompiled it from scratch. After doing this, I encountered the exception described above.

After a bit of digging, I discovered that the 'Struct Member Alignment' setting was the culprit:

Project properties > Configuration Properties > C/C++ > Code Generation > Struct Member Alignment

While the Frameworks project had the setting set to 'default', the corresponding Unit Test project had it configured to "1 Byte /Zp1". Once I changed them to have the same alignment, the problem went away.

This answer allowed me to find my problem. I head tested library configured as "Runtime Library: Multi-threaded DLL /MD" and testing app as "Runtime Library: Multi-threaded Debug DLL /MDd". As a result I was getting the same error as in the subject. Thanks. — Janusz Grabis, Jan 21 '16 at 16:02

score 4 · Answer 4 · answered Feb 08 '16 at 13:35

For me it appeared to be a null reference error. Some method was called on a nullptr and for reasons unclear to me it didn’t fail immediately but just started executing. The SEH error presumably occurred as soon as unallocated memory was accessed. So check for null pointers!

TrustyCoder · Answer 5 · 2017-03-29T03:49:12.180

3

I am having a similar issue and its pertaining to un-initialized variables and running the test in release build. I had a char * un-initialized after which initialized to NULL seems to have fixed the issue.

edited Mar 29 '17 at 03:49

answered Mar 29 '17 at 03:34

TrustyCoder

4,749
10
66
119

Confirmed. That fixed the issue. No more un-initialized variables in C++. – TrustyCoder Mar 29 '17 at 13:48

score 1 · Answer 6 · answered Oct 19 '16 at 15:38

If you are using Visual Studio 2013, check the Thrown box for Win32 exceptions (specifically access violation) in Debug>Exceptions. This will let you debug which line has the issue. This might be useful since the debugger will not break if your program normally raises other exceptions.

score 1 · Answer 7 · answered Dec 30 '20 at 01:28

1

destroying null pointer can be a reason. I found out through Visual Studio > Exception > Select All. Then run local windows debugger, it stopped at line where exception occurred.

answered Dec 30 '20 at 01:28

Ankita Kalra

11
1

score 0 · Answer 8 · answered Dec 13 '19 at 08:27

Ran into this problem using msvc in qt. SEH was thrown almost randomly, for no apparent reasons. (read: didn't have any time left to look into it) After NOT finding the right solution and the tests seemed to work for non-windows users, I switched to MinGW which ran the tests normally.

MrAlbino · Answer 9 · 2022-05-07T19:01:24.053

0

I was trying to delete a memory address which was already deleted. This was the problem in my case so i suggest to look for null pointers.

edited May 07 '22 at 19:01

answered May 07 '22 at 18:56

MrAlbino

308
2
10

score 0 · Answer 10 · answered Aug 08 '23 at 21:09

I am using Gtest with Protobuf on VS and I am seeing the issue where the test's checked(Debug) build was crashing with an exception, but not the free(Release) build.

To use protobuf, I followed instructions here, the vcpkg install for windows in particular.

Turns out Gtest project was inheriting the libs in linker from parent and ended up getting linked to libprotobuf and libprotobuf_lite, and not the libprotobufd and libprotobuf_lited, the latter are the debug versions. This is because by default the path in the Additional Dependencies under Properties->Linker->Input ends up providing the option to link with $(_ZVcpkgCurrentInstalledDir)$(_ZVcpkgConfigSubdir)lib*.lib , which is where the free build of protobuf libs reside.

Changing the path to $(_ZVcpkgCurrentInstalledDir)$(_ZVcpkgConfigSubdir)debug\lib*.lib solved the issue and the exceptions were gone.

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). — Community, Aug 11 '23 at 22:34

SEH exception with code 0xc0000005 thrown in the test body

10 Answers10

Linked