Boost C++ Libraries: Ticket #5553: Access violation caused by boost::unit_test::make_test_case on Windows

Gennadiy Rozental — Mon, 17 Oct 2011 04:48:51 GMT

Why don't you use debug version of UTF?

Mon, 17 Oct 2011 17:30:43 GMT

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.

status changed; resolution set

Gennadiy Rozental — Mon, 05 Nov 2012 02:10:43 GMT

status new → closed
resolution → wontfix

I do not see anything for us to fix here.

andrepuel@… — Sat, 05 Jan 2013 05:22:16 GMT

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.

status, version changed; resolution deleted

anonymous — Sat, 05 Jan 2013 05:22:51 GMT

status closed → reopened
version Boost 1.44.0 → Boost 1.52.0
resolution wontfix

status changed; resolution set

Raffi Enficiaud — Sun, 28 Dec 2014 00:23:05 GMT

status reopened → closed
resolution → wontfix

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.