How does gtest handle segmentation violations in its own code?

[MarkCallow]

All my gtest-based test programs are crashing with a segmentation violation (error code 139) after the test suite successfully completes and after successfully listing the tests. This is with 1.18.0 (other versions not tested) and only when compiled with gcc (version 13.2/MinGW 13.2; other versions not tested) on an x86_64 processor. On an arm64 processor or when compiled with MSVC or ClangCL the problem does not occur. I have been trying without success to capture a crash dump on the failing CI because I do not have an x86_64 computer on which to reproduce the problem locally. I even tried procdump which reports that the process exited with code 0 yet the CI still reports a failure.

This leads to the question does gtest catch segmentation violation exceptions and handle them itself so Windows does not see them? If so, how can I get a crashdump or stack trace?

[5h4d0wn1k]

On x86_64 MinGW/gcc, if the crash happens after RUN_ALL_TESTS returns, it can be related to teardown/global destructors. gtest itself doesn't catch segfaults by default; on Windows with SEH you could wrap, but with POSIX signals you'd need a handler.

For debugging CI: try running with --gtest_catch_exceptions=0 to let the crash surface natively (or capture dumps via CI tooling). Also check if any static/global objects are being destroyed after gtest exits. A stack trace from a core dump would help narrow this down.

[5h4d0wn1k]

gtest doesn't catch SEGVs/signals by default. On Windows, SEH exceptions differ; on POSIX, unhandled signals terminate the process. After RUN_ALL_TESTS returns, crashes often come from static/global destructor order (including DLL teardown on MinGW/x86_64).

Try --gtest_catch_exceptions=0 in CI to surface the native crash, and collect a core/dmp. Also test with sanitizers (ASan/UBSan) or -fno-omit-frame-pointer + symbols. procdump can fail if the process exits "cleanly" in gtest's wrapper — catch at OS level instead.

[5h4d0wn1k]

gtest doesn't catch SEGVs/signals by default. On POSIX, unhandled signals (like SIGSEGV) terminate the process immediately. On Windows, crashes are SEH exceptions — gtest's --gtest_catch_exceptions only affects C++ exceptions (std::exception), not hardware faults/SEH by default.

The post-RUN_ALL_TESTS crash on x86_64 MinGW/gcc is common due to global/static destructor order, including DLL teardown. If destructors access already-unloaded libs or depend on order, you get faults at process exit.

Quick fixes for CI:

• Run with --gtest_catch_exceptions=0 to let the OS catch the native crash (helps get a real dump).
• Collect a core dump (Linux) or full minidump (Windows). Tools like procdump can miss if gtest's wrapper masks exit; use OS-level capture (e.g. coredumpctl, WER/local dump rules).
• Reproduce with sanitizers: -fsanitize=address,undefined builds often expose destructor issues. Also try -fno-omit-frame-pointer + debug symbols.
• Avoid globals whose dtors touch other singletons; consider atexit/explicit cleanup or using function-local statics carefully.

If you share a stack trace, it's easier to pinpoint the exact destructor. But based on "after successful test run on MinGW x86_64", teardown ordering is the likely culprit.

[MarkCallow]

@5h4d0wn1k, thank you for your advice. I already have WER local dump rules set up but am not getting any crash dumps, hence this thread. I tried --gtest_catch_exceptions=0 but there was no difference in output or result and still no crashdump. We do run a job with sanitizers in our Linux/Ubuntu workflow and all problems it showed have been fixed. I added sanitizers to the problematic MinGW job. As with our gcc/Ubuntu job, no issues are reported.

I will try coredumpctl as soon as I have time.

If you share a stack trace

That is what I am struggling to obtain and why I need a crashdump.

gtest doesn't catch SEGVs/signals by default. ... Tools like procdump can miss if gtest's wrapper masks exit; use OS-level capture (e.g. coredumpctl, WER/local dump rules).

The two statements on each side of the ellipsis seem to conflict.

What is this gtest wrapper and how does it mask exit? Is there documentation?

[MarkCallow]

Before I could try coredumpctl, a colleague with x86_64 hardware was able to reproduce the issue locallly. He determined that the crash happened when the gtest-linked programs were run from Git Bash and did not happen when run from PowerShell. The fix he found is to build gtest as a static library. (When I tried to use procdump I was using PowerShell which explains the 0 exit when I was trying to use procdump that I reported earlier.)

Note that when building gtest as a dll I was setting gtest_force_shared_crt. I do not understand why running under Git Bash caused the crash.

Thanks again to @5h4d0wn1k for your help.

[MarkCallow]

The answer to the question I posed is

"gtest doesn't catch SEGVs/signals by default." - @5h4d0wn1k.