Opened 4 months ago

Closed 13 days ago

#13528 closed Bugs (fixed)

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

Reported by: igor.akhmetov@… Owned by: Raffi Enficiaud
Milestone: Boost 1.68.0 Component: test
Version: Boost 1.67.0 Severity: Showstopper
Keywords: Cc:

Description

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.

Change History (6)

comment:1 Changed 4 months ago by Raffi Enficiaud

Owner: changed from Gennadiy Rozental to Raffi Enficiaud
Status: newassigned

comment:2 Changed 8 weeks ago by 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?

comment:3 Changed 8 weeks ago by 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.

comment:4 Changed 8 weeks ago by Raffi Enficiaud

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

comment:5 Changed 8 weeks ago by Raffi Enficiaud

Milestone: To Be DeterminedBoost 1.68.0

comment:6 Changed 13 days ago by Raffi Enficiaud

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.