// This is a hack to implement death tests in CTest.
extern "C" void error_test_handle_abort(int) {
std::_Exit(EXIT_FAILURE);
}
struct test_override_abort {
test_override_abort() noexcept {
std::signal(SIGABRT, error_test_handle_abort);
}
};
test_override_abort handler{};
```
seems to hack around it. I imagine this is something similar to what Google Test does, but with an ugly unused global variable. I think there should be first-class support for death tests in CTest, though. `WILL_FAIL` should be supplemented by a new `WILL_ABORT` property.
---
### Author:  [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [January 27, 2020, 11:35pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/5 "2020-01-27T23:35:03Z")
@craig.scott - I wonder if you know of any alternatives to the above workaround?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 27, 2020, 11:45pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/6 "2020-01-27T23:45:33Z")
It’s a bit odd to explicitly expect an application to abort. There could be any number of reasons why it might abort/crash and it’s not normal for that to be expected behavior! That said, one possibility is maybe you could wrap it in a call like `ctest --build-and-test` somehow. I haven’t thought it through and maybe it’s a completely wrong-headed, over-engineered way to tackle it, but it’s something you could explore at least. I’m a bit short on time right now, so I’ll have to leave you to investigate further.
---
### Author:  [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [January 27, 2020, 11:49pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/7 "2020-01-27T23:49:32Z")
No worries and thanks very much for getting back to me! Your book has been invaluable in retrofitting cmake to this project, by the way 🙂
---
### Author:  [@steven-johnson](https://discourse.cmake.org/u/steven-johnson)
#### Post date: [November 25, 2020, 10:49pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/8 "2020-11-25T22:49:15Z")
> There could be any number of reasons why it might abort/crash and it’s not normal for that to be expected behavior!
It’s totally reasonable to have tests that are “expected to fail”, e.g., we expect this code to have an assert() fail if we pass in this set of malformed inputs. Since assert() often uses SIGABRT, being able to catch these is highly desirable. (I’m pretty sure that GTest allows for catching expected-SIGABRT via the EXPECT\_DEATH/ASSERT\_DEATH macros.)
---
### Author:  [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [November 26, 2020, 1:57am UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/9 "2020-11-26T01:57:26Z")
> (I’m pretty sure that GTest allows for catching expected-SIGABRT via the EXPECT\_DEATH/ASSERT\_DEATH macros.)
The `_DEATH` macros are wrappers for the `_EXIT` macros, which use platform-specific APIs (`fork` on NIX and `CreateProcess` on Windows) to run the statement in a child process, isolating the parent process from its errors.
CTest never sees the `SIGABRT` when using GTest.
See: [https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#how-it-works](https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#how-it-works)
---
### Author:  [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [December 4, 2020, 6:56pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/10 "2020-12-04T18:56:13Z")
I have an analogous issue with `WILL_FAIL` and segfaults. I made an interface to a large external library out of my control, and I want to test that bad inputs do fail. Sometimes (shaky) the external library segfaults, which then causes CTest to fail despite WILL\_FAIL. Most of the time the external library doesn’t segfault, but returns an error code, which of course works OK with WILL\_FAIL
My workaround was to skip these cases on CI and remember to run them locally.
However, I can see that others might expect that segfaults are indeed a “third outcome” that isn’t desirable.
---
### Author:  [@perlun](https://discourse.cmake.org/u/perlun)
#### Post date: [August 21, 2023, 7:44pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/11 "2023-08-21T19:44:24Z")
Discovering/hijacking this a few years later (…), I can add that processes raising `SIGABRT` (e.g. using asserts which call `abort()`) will cause ctest to print `Exception:Subprocess aborted` and _not show the output from the failing program_ despite how hard I try to make it: passing `--extra-verbose` or setting `CTEST_OUTPUT_ON_FAILURE=1` in the environment won’t make a single bit of a difference.
Then when I switched the assertion code in my project to use `exit(1)` instead, it instantly started working.
Is this by design or is this a limitation in ctest/cmake? I’ll readily admit I am (_very_ much) a newbie user of cmake. The versions I’ve tested thus far are 3.24.2 which comes bundled with my CLion and 3.25.1; both seem to exhibit the same behaviour. The exception (in ctest) is typically thrown at this line: [https://github.com/Kitware/CMake/blob/v3.25.1/Source/CTest/cmCTestRunTest.cxx#L255](https://github.com/Kitware/CMake/blob/v3.25.1/Source/CTest/cmCTestRunTest.cxx#L255), which can be seen when running ctest with `--debug`.
Any ideas?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 21, 2023, 8:57pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/12 "2023-08-21T20:57:14Z")
Moderator note: Rather than hijacking a thread, it’s generally better to start a new thread and link to other related threads.
If I had to guess, I’d say what is happening in your case is that your standard output isn’t getting flushed, so you’re losing that output (which would have nothing to do with ctest). Note that `exit()` does flush all output C streams, whereas I don’t believe `abort()` does.
---
### Author:  [@perlun](https://discourse.cmake.org/u/perlun)
#### Post date: [August 22, 2023, 6:57pm UTC](https://discourse.cmake.org/t/tests-that-are-meant-to-abort/537/13 "2023-08-22T18:57:00Z")
> [@craig.scott](#):
>
> If I had to guess, I’d say what is happening in your case is that your standard output isn’t getting flushed, so you’re losing that output (which would have nothing to do with ctest). Note that `exit()` does flush all output C streams, whereas I don’t believe `abort()` does.
Thanks for this - you’re of course right about not hijacking threads as well. 🙈 I moved this to [a separate discussion](https://discourse.cmake.org/t/why-does-my-test-calling-abort-not-output-anything/8803) now and posted a reply there. 👍