At least in VS 2015, the c++ stdlib reports violated asserts with a message box prompted to the user. This breaks CI services such as Appveyor, which only show the terminal output and do not allow one to react to the message box. From the user point of view, the build simply stalls for no reason at some point in time without any message as to why.
As Peter pointed out, the issue can be fixed by calling these two functions before the code trips any assert:
I think this should be set automatically when lightweight_test is used. The class test_result has some code to change the abort behaviour already. However, this change is triggered only when test_result is first used, which is on the first BOOST_TEST call. The assert may be triggered before. Another option is to use some code like this somewhere in the detail namespace of lightweight_test.hpp
At least in VS 2015, the c++ stdlib reports violated asserts with a message box prompted to the user. This breaks CI services such as Appveyor, which only show the terminal output and do not allow one to react to the message box. From the user point of view, the build simply stalls for no reason at some point in time without any message as to why.
As Peter pointed out, the issue can be fixed by calling these two functions before the code trips any assert:
See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/assert-asserte-assert-expr-macros?view=vs-2019 https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/crtsetreportmode?view=vs-2019
How to handle this?
I think this should be set automatically when lightweight_test is used. The class
test_result
has some code to change the abort behaviour already. However, this change is triggered only whentest_result
is first used, which is on the firstBOOST_TEST
call. The assert may be triggered before. Another option is to use some code like this somewhere in the detail namespace of lightweight_test.hppThe complicated initialization order of globals may be an issue. https://stackoverflow.com/questions/3746238/c-global-initialization-order-ignores-dependencies/3746249#3746249