Boost Test 1.67 crashes when the --report_sink command-line parameter is used

[igor.akhmetov@…]

Environment: Visual Studio 15.6, 64-bit build of Boost.

Scenario: a Boost.Test executable crashes with an access violation when run with the -e command-line argument.

Cause: Boost.Test has two global singletons, a framework::state instance inside s_frk_state() and a results_reporter_impl instance inside s_rr_impl(). Their relative destruction order is undefined, in my case the results_reporter_impl instance is destroyed before the framework::state instance. The following sequence of events then takes place:

1) framework::state::~state destroys the m_report_sink member, leading to the stream_holder::~stream_holder call.

2) stream_holder::~stream_holder destroys m_cleaner, which calls stream_holder::callback_cleaner::~callback_cleaner.

3) stream_holder::callback_cleaner::~callback_cleaner calls the m_cleaner_callback callback, which was passed from framework::init.

4) The callback calls results_reporter::set_stream.

5) results_reporter::set_stream accesses the results_reporter_impl singleton instance, which has been already destroyed, and the program crashes.

[Raffi Enficiaud]

Hi,

I am looking at this now, and there is something I do not get in your report (thank you for the level of details BTW).

During the stream_holder::callback_cleaner::~callback_cleaner, there is a test about the callback:

        ~callback_cleaner() {
            if( m_cleaner_callback )
                m_cleaner_callback();
        }

and m_cleaner_callback should have been resetted to an empty function during the call to shutdown_loggers_and_reports() (in the framework::shutdown call).

So I am not sure to understand why this is happening for you. Are you still able to reproduce? In that case, are you entering the call to the callback?

[Igor Akhmetov <igor.akhmetov@…>]

Sorry, missed a detail - I was also using the --list_content command-line argument. When either --list_labels or --list_content are used, unit_test_main exits prematurely and does not call framework::shutdown.

[Raffi Enficiaud]

Go it, thanks! I am able to reproduce and easily fix this.