• Advertisement

Running x86 build crashes

Recommended Posts

I have 4 build configurations in Visual Studio 2017 15.5.2 (/std:c++latest) that build without a single error or warning (though, I suppressed some warnings about adding padding for alignment and about the usage of anonymous structs): Release|Debug x64 and Release|Debug x86. All the builds run fine except for Release x86 which crashes at some weird fixed location (in fact two weird fixed locations, since I have alternatives for my input file formats).

The output mentions a very informative message:

Quote

Exception thrown: read access violation.
**__that** was 0x1.

Some of my C++ Locals (std::strings) had a value equal to some of my HLSL statements and comments, but that does not seem to repeat itself.

I suspect an alignment bug (my x64 builds never had a problem), but I have no idea how to track these down?

  • I checked if all my struct/classes that are declared alignas are allocated with a custom allocator when stored in std::vector.
  • All structs/classes storing XMVECTOR/XMMATRIX data are declared alignas(16).
  • Furthermore, I checked all my call conventions for functions with XMVECTOR/XMMATRIX return or input argument types (this fixed the Debug x86 build, which didn't crash but produced weird shadows).

Any ideas?

Share this post


Link to post
Share on other sites
Advertisement

Are you generating dump files?  Adding crash handlers that call MiniDumpWriteDump() is incredibly useful if you are keeping the pdb files around. By saving all the memory with the right flags you can see exactly where the program was and exactly what was in memory when it died, including full stacks for each thread.

Without tools like that it is mostly guesswork.  You guessed several items, alignment issues, structure packing, wrong calling conventions, differences between structures in different builds.  Maybe any of those, maybe none of those. Get an actual dump file so you can verify for certain, or find steps to reproduce it inside a debugger.

Share this post


Link to post
Share on other sites

Try gradually enabling the same optimisation settings in your debug build that you use in your release build to see if you can catch the issue in the debugger - you might be able to catch it that way.

Share this post


Link to post
Share on other sites
9 hours ago, C0lumbo said:

Try gradually enabling the same optimisation settings in your debug build that you use in your release build to see if you can catch the issue in the debugger - you might be able to catch it that way.

Unfortunately, the MVC++ compiler flags triggering the problem are anything except /Od (no optimizations) + /GL (Whole Program Optimization). So the /GL flag is the culprit, but cannot be debugged properly with Visual Studio itself.

 

I am going to try the file dump method later on (reminder to self: http://www.debuginfo.com/examples/effmdmpexamples.html)

Edited by matt77hias

Share this post


Link to post
Share on other sites

I couldn't use __try due to the object unwinding. So I switched /EHsc to /EHa and put all my startup code in a noexcept function. The program crashes with an "exception" (SEH?), though my crash dump function is never called?

__try {
        Run(hinstance, nCmdShow);
    }
__except (CreateMiniDump(GetExceptionInformation()), EXCEPTION_EXECUTE_HANDLER) {}

 

Share this post


Link to post
Share on other sites

There are many other ways to do it because there are many different reasons for programs to get killed.

You can set an unhandled exception handler for your program, std::set_terminate() for C++ exceptions. If you use Windows Structured Exceptions you also need SetUnhandledExceptionFilter(). Depending on how your program dies you may want to register functions with std::atexit() and/or std::at_quick_exit(). 

In current versions of Windows you can also set some registry values to turn on Windows Error Reporting (WER) to generate crash dumps even if those above methods don't catch it.

Share this post


Link to post
Share on other sites
11 hours ago, frob said:

Windows Structured Exceptions you also need SetUnhandledExceptionFilter()

But in my specific case, I need to look into this one? (Because the noexcept could not leak C++ exceptions; i.e. the program would just terminate instead of crash). 

Share this post


Link to post
Share on other sites
12 hours ago, frob said:

There are many other ways to do it because there are many different reasons for programs to get killed.

Ok apparently both 

LONG WINAPI UnhandledExceptionFilter(EXCEPTION_POINTERS *exception_record) {
    CreateMiniDump(exception_record);
    return EXCEPTION_CONTINUE_SEARCH;
}

void AddUnhandledExceptionFilter() noexcept {
    SetUnhandledExceptionFilter(UnhandledExceptionFilter);
}

and

__except (CreateMiniDump(GetExceptionInformation()), EXCEPTION_EXECUTE_HANDLER) {}

work. Visual Studio was interfering with the exception handling. When I just run the .exe outside Visual Studio, it crashes and generates the dump file. The former does not require __try/__catch and so I can get rid of /EHa, furthermore you get some crash message. The latter does not result in some crash message since the program will catch everything..

Edited by matt77hias

Share this post


Link to post
Share on other sites

@frob I used a very verbose mini dump including MiniDumpWithFullMemory | MiniDumpWithFullMemoryInfo | MiniDumpWithHandleData | MiniDumpWithThreadInfo | MiniDumpWithUnloadedModules and generated the mini dump (168 MB), but how does one do something useful with the file? The default program for opening the .dmp file is Visual Studio itself. The only "useful" action seems "Debug with Native Only", though that results in the same info Visual Studio gave in the first place?

Clipboard01.thumb.jpg.b3d1204b0717a6ce82ba54ac4a254779.jpg

 

As a side note, SIMD intrinsics are not the problem, since the program still crashes with the same error after disabling them. This begins to make me really suspicious (again) towards the compiler/linker itself.

Edited by matt77hias

Share this post


Link to post
Share on other sites

Did you check the call stack that is shown with your minidump? That seems to point to a very concrete location, and should probably allow you to spot the error (which seems to relate to eigther vector pushback or your ModelPart-move-ctor).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement