Opened 13 years ago

Closed 13 years ago

#3436 closed Bugs (worksforme)

Code miscompilation with MSVC 7.1

Reported by: Andrey Semashev Owned by: Gennadiy Rozental
Milestone: Boost 1.41.0 Component: test
Version: Boost 1.40.0 Severity: Problem
Keywords: msvc Cc:

Description

While trying to compile Boost.Test 1.40 with MSVC 7.1 into a shared library I found out that the library crashed during initialization.

Apparently, the crash was because of the broken code compilation in the library. The problem is that the typed_parameter< ... >::accept_modifier method is called on invalid this pointer. It looks like MSVC 7.1 has a hard time in compiling operator<< and operator- when it accepts shared_ptr by value. When I changed the operators to accept const references everything worked fine.

Please find the patch attached. It may also be useful to speed up test startup, aside for the MSVC 7.1 cure.

Attachments (1)

cla.patch (1.7 KB ) - added by Andrey Semashev 13 years ago.
The fix for code miscompilation on MSVC 7.1

Download all attachments as: .zip

Change History (4)

by Andrey Semashev, 13 years ago

Attachment: cla.patch added

The fix for code miscompilation on MSVC 7.1

comment:1 by Gennadiy Rozental, 13 years ago

Resolution: worksforme
Status: newclosed

Works fine for me. In fact I believe shared library build is part of routine regression tests.

Are you sure it's not something specific to your setup? Do you have an example which reproduces this?

Also what to you mean by speedup startup? How long does it take for you?

comment:2 by Andrey Semashev, 13 years ago

Resolution: worksforme
Status: closedreopened

Works fine for me. In fact I believe shared library build is part of routine regression tests.

I'm not sure Boost.Test is build as a shared library with my options in the regular testing process.

Are you sure it's not something specific to your setup? Do you have an example which reproduces this?

I have described my setup in ticket #3435. I still have problems with 1.41 Boost release (after the patch from #3435 is applied), although the test now simply ends with the "Boost.Test framework internal error: unknown reason" message instead of a crash. I don't have much time to dig deeper now, but I suspect that the root of the problem is still the same.

Here is my test case:

#define BOOST_ALL_DYN_LINK
#define BOOST_TEST_MAIN

#include <boost/test/unit_test.hpp>
#include <boost/test/test_tools.hpp>
#include <boost/test/unit_test_suite.hpp>

BOOST_AUTO_TEST_CASE(MyTest)
{
    BOOST_CHECK(true);
}

I compile it with the following commad line:

cl -Ox -I ../STLport/stlport -I . -EHsc -MD ./test.cpp

Where . is in the boost 1.41 directory. However, I believe, pretty much any test case is affected.

Also what to you mean by speedup startup? How long does it take for you?

It's not something I measured or intentionally wanted to speedup. It was just a side effect of the proposed patch. We have several thousands of tests here, many of them are using Boost.Test. If each particular test starts a bit faster, it has an observable effect on our testing as a whole. But since without the patch none of the tests work, I don't have anything to compare with.

comment:3 by Gennadiy Rozental, 13 years ago

Resolution: worksforme
Status: reopenedclosed
  1. Shared library is default build with bjam, thus unless one intentionally change it shared library is being used.
  1. Please check my comments ot #3435. I am pretty sure here is something similar, cause I can't reproduce it in my setup. If you still see the issue, please resubmit with and example and all the details about how you build both test module and test library

P.S. You only need 1 include: #include <boost/test/unit_test.hpp>

Note: See TracTickets for help on using tickets.