Opened 11 years ago

Closed 8 years ago

#5553 closed Bugs (wontfix)

Access violation caused by boost::unit_test::make_test_case on Windows

Reported by: Balint SZENTE <balint@…> Owned by: Gennadiy Rozental
Milestone: To Be Determined Component: test
Version: Boost 1.52.0 Severity: Problem
Keywords: windows, memcpy, make_test_case Cc:

Description

The unit test main application built in DEBUG mode generates access violation with non debug version of Boost shared libraries on Windows platform.

Steps to reproduce:

  • Test file:
    #define BOOST_TEST_MODULE "Test"
    #include <boost/test/unit_test.hpp>
    
    using namespace boost;
    
    BOOST_AUTO_TEST_SUITE(Suite)
    BOOST_AUTO_TEST_CASE(Case) {
    }
    BOOST_AUTO_TEST_SUITE_END()
    
  • Compile with Visual C++ 2010 in DEBUG mode having the following defines enabled:
    BOOST_ALL_DYN_LINK
    BOOST_ALL_NO_LIB
    
  • Link with the non debug versions of Boost DLLs taken from the [boostpro.com] website (version 1.46.1 or 1.44 for example)
  • Run the program

Expected result:

Running 1 test cases...

*** No errors detected

Actual result: the program will crash in msvcr100.dll in memcpy function with illegal addresses. The callstack:

msvcr100.dll!memcpy(unsigned char * dst, unsigned char * src, unsigned long count)  Line 311
boost_unit_test_framework-vc100-mt-1_44.dll!10002e29() 	
[Frames below may be incorrect and/or missing, no symbols loaded for boost_unit_test_framework-vc100-mt-1_44.dll]	
boost_unit_test_framework-vc100-mt-1_44.dll!1003298f() 	
boost_unit_test_framework-vc100-mt-1_44.dll!10032a9d() 	
boost_utf.exe!boost::unit_test::make_test_case(const boost::unit_test::callback0<boost::unit_test::ut_detail::unused> & test_func, boost::unit_test::basic_cstring<char const > tc_name)  Line 255 + 0x8d bytes

Note:

  • The program linked with the DEBUG version of the Boost DLLs works properly. It seems that Boost.Test module generates different codepaths and the Debug and non debug versions of the DLLs are not functionally compatible.
  • On Linux this issue does not exist. The DEBUG version of the application works well with the non debug version of boost_unit_test_framework shared object files.

Change History (6)

comment:1 by Gennadiy Rozental, 11 years ago

Why don't you use debug version of UTF?

comment:2 by Balint SZENTE <balint@…>, 11 years ago

Actually that's what I'm doing now.

To answer your question... I usually use release version of 3rd party libraries when I develop a program, because I'm fond of production builds, not the debug ones. However, I realize that Boost is massively header implemented making the compiler's job significantly harder.

I made the bug report to notify this behavior with Microsoft Visual C++, because I could not decide whether this is normal or not, taking into account the fact that on Linux and Max OS X they work well. I did not expected the debug and release builds to be incompatible in such a way that they might result even in crash. Ideally they should be perfectly interchangeable from ABI point of view.

comment:3 by Gennadiy Rozental, 10 years ago

Resolution: wontfix
Status: newclosed

I do not see anything for us to fix here.

comment:4 by andrepuel@…, 10 years ago

I am using Microsoft Visual Studio 2012 Ultimate and boost 1.52.0.

I've compiled boost myself only in release mode. If I compile my tests with debug mode I get the same access violation on make_test_case.

If this is the intended behavior I suggest some kind of warning or error if someone tries to use release dll on debug compiled test, because I have had a hard time trying to figure out what was causing the access violation.

comment:5 by anonymous, 10 years ago

Resolution: wontfix
Status: closedreopened
Version: Boost 1.44.0Boost 1.52.0

comment:6 by Raffi Enficiaud, 8 years ago

Resolution: wontfix
Status: reopenedclosed

The behaviour is well known on Windows: the test module and the boost.test dll should link to the same CRT (Visual C and C++ dll), otherwise they won't use the same heap for instance, which leads to the crashes you describe. This is simply because the API of boost.test contains objects that are not POD. This will be mentionned in the documentation.

Note: See TracTickets for help on using tickets.