catchorg
Disabling signals is broken in V3
Describe the bug It is not possible to disable signals in Catch2 V3 when it is prebuild into a static library.
Expected behavior
In V2 it was possible to disable signals/SEH with defining CATCH_CONFIG_NO_POSIX_SIGNALS and CATCH_CONFIG_NO_WINDOWS_SEH because it was a header only library. It would be nice if this would also possible for V3 without the need to build the library yourself.
Reproduction steps The problem is also described here: https://github.com/catchorg/Catch2/issues/1295#issuecomment-925820850 The example code is trying to disable the signals like in V2, but in V3 these defines need to be defined when building the library itself.
Platform information:
- OS: Linux / Windows
- Catch version: v3
Additional context I'm maintaining a fork of Sourcetrail which contains tests for JNI/JVM function calls. The JVM is internally using signals and this will lead to test failures because Catch2 intercepts these signals and reports a SIGSEGV.
I probably don't need to mention this, but this issue might become more urgent when Debian/Ubuntu starts to deploy a prebuild Catch2 V3 via their repositories.
I concur. The current implementation uses the same compile time flag (CATCH_CONFIG_NO_POSIX_SIGNALS) but since we now have a compiled version of the library, trying to change that flag in each individual project is futile.
On my end, I'll look to having two versions available for my projects. I have a couple of libraries where I want to be able to test Unix signals and as it stands, Catch2 v3 prevents me from doing it. It's a rather rare situation, but certainly useful to properly document if it is not going to be possible to switch the library one way or the other when used in different projects.
Now with Ubuntu 24.04 out, I'm running in the described problem, that I can't disable the POSIX signal handling. :frowning_face:
My project has moved to vcpkg for C++ dependency management and now we don't have a way to set CATCH_CONFIG_NO_POSIX_SIGNALS and CATCH_CONFIG_NO_WINDOWS_SEH. I would like these options to be runtime controllable, but if asked I would just argue that the options should be removed altogether. I cannot think of any situation where it is better for Catch2 to handle posix signals or use Windows SEH. All it can do with it is hurt diagnosability. If the signal/seh exception is not caught by Catch2 I can get a core/dmp file and I can get all the available information to diagnose the problem. If Catch2 deals with it I get just the name of the test/section and the name of the signal/exception. This may be sufficient for small unit tests, but it is never ideal, and for tests that test a "larger unit" it is pretty close to useless.
For vcpkg based projects there actually exists a way to configure it with custom tripplets. See here: https://github.com/petermost/Sourcetrail/tree/2024.8.2/vcpkg-custom-tripplets for further details.
For vcpkg based projects there actually exists a way to configure it with custom tripplets. See here: https://github.com/petermost/Sourcetrail/tree/master/vcpkg-custom-tripplets for further details.
That's nice. I would suggest to guard the extra line with if(PORT STREQUAL "catch2").
For vcpkg based projects there actually exists a way to configure it with custom tripplets. See here: https://github.com/petermost/Sourcetrail/tree/master/vcpkg-custom-tripplets for further details.
That's nice. I would suggest to guard the extra line with
if(PORT STREQUAL "catch2").
Do I understand this correctly, that this would apply/limit the configuration only when 'catch2' is being build?
Do I understand this correctly, that this would apply/limit the configuration only when 'catch2' is being build?
Yes. Cf. https://learn.microsoft.com/vcpkg/users/triplets#per-port-customization
Because I want to fix the spelling error in 'vcpkg-custom-tripplets' I post the URL again with a versioned tag: https://github.com/petermost/Sourcetrail/tree/2024.8.2/vcpkg-custom-tripplets