You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a unit test project in which exceptions rely on test fixture's state. This can lead to use-after-free situations, because uncaught exception objects can outlive fixture. Following code illustrates the problem:
Context::Context
ErrorUsingContext::ErrorUsingContext
Context::~Context
ErrorUsingContext::what
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
output.s is a Catch v3.0.0-preview.3 host application.
Run with -? for options
-------------------------------------------------------------------------------
Test
-------------------------------------------------------------------------------
/app/example.cpp:32
...............................................................................
/app/example.cpp:32: FAILED:
due to unexpected exception with message:
description allocated and managed by Context
ErrorUsingContext::~ErrorUsingContext
===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed
ErrorUsingContext::what is called after Context::~Context which is a problem for me, because, in my case, memory of exception's description string is allocated and managed by the Context (strings use custom allocators).
I can work around it, but this could be avoided if uncaught exceptions' description were retrieved and saved by Catch2 before calling fixture's destructor.
The text was updated successfully, but these errors were encountered:
I have a unit test project in which exceptions rely on test fixture's state. This can lead to use-after-free situations, because uncaught exception objects can outlive fixture. Following code illustrates the problem:
Godbolt: https://godbolt.org/z/xf3x65rhe
Output:
ErrorUsingContext::what
is called afterContext::~Context
which is a problem for me, because, in my case, memory of exception's description string is allocated and managed by theContext
(strings use custom allocators).I can work around it, but this could be avoided if uncaught exceptions' description were retrieved and saved by Catch2 before calling fixture's destructor.
The text was updated successfully, but these errors were encountered: