date_time causes "debug assertion failed" error in windows forms application, with visual c++ express 2010

[crillion@…]

Hi,

I have a debug assertion failure which arises when I include boost/date_time/gregorian.hpp.

I had found this problem in a complex windows forms project, using visual c++ express 2010 (everything worked fine with visual c++ express 2008). I have been able to reduce the problem to a simple case. I've seen this problem happening with boost 1.44.0 and boost 1.45.0 (I didn't test it with previous versions).

I have currently a build of boost (both of 1.44.0 and 1.45.0) obtained with the command

bjam --prefix="..\boost_1_45_0_build" install

which has worked normally.

In synthesis, the steps are:

• I create a Visual C++ Windows Form Application
• in the project properties, I set the CLR support switch for the project from default (/clr:pure) to /clr (used for mixed code)
• please note that I set this switch in 2 points of the project properties tree: 1) Configuration Properties/General->Common Language Runtime Support, and 2) Configuration Properties/ C/C++ /General->Common Language Runtime Support
• in the stdafx.h file I add the inclusion

#include <boost/date_time/gregorian/gregorian.hpp>

• I build the solution
• I run the project

Without even running a line of code (I cannot even debug it, although I'm in debug mode), a dialog box appears with the following error message:

---

Debug Assertion Failed!

Program: ...epository1\applications\test_vc2010_4\Debug\test_vc2010_4.exe File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c Line: 1516

Expression: _CrtIsValidHeapPointer(pUserData)

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

---

Pressing retry I go to an involved system file, not even to a boost source code file or to one of my source files.

It seems that the error rises in a part of windows / C++ / .NET runtime, provoked by something in the date_time library which is examined by the runtime before running the program.

I've searched a lot, but while this error message is common, the correlation with boost seems to be less known. I'm also sure about the CLR switch, in the project properties, which is to be set as /clr (if no /clr support is given, I cannot use windows forms, and if I use /clr:pure, every other project I use will have to be compiled as pure). That is, the error gets bypassed if I switch to /clr:pure, but that would force me to convert any other projects to this format, which at a certain point becomes impossibile with projects containing native c++ classes.

I've been able to see that the same project settings work with a CLR Console application (so it doesn't seem to be .NET itself the cause of the problem).

So, what can be done to avoid this ?

Please let me know if you need help to reproduce the problem.

Many thanks,

Marco

[Vicente Botet <vicente.botet@…>]

I would not say this is a bug on DateTime. What about changing this to a support request on Building Boost?

[Marco Pappalepore <crillion@…>]

Replying to Vicente Botet <vicente.botet@…>:

I would not say this is a bug on DateTime. What about changing this to a support request on Building Boost?

yes, but the fact is that boost builds, and the program compiles; it seems that this error is raised at runtime, before the real program itself starts, just when the runtime makes some checks before calling it. So it is appearently a runtime problem: perhaps not of the library failing by itself, but not passing a runtime check. So I'm doing this way: I wait still for some hours, for seeing any answer, then I switch it to build-boost.

[Marco Pappalepore <crillion@…>]

Replying to Marco Pappalepore <crillion@…>:

Replying to Vicente Botet <vicente.botet@…>:

I would not say this is a bug on DateTime. What about changing this to a support request on Building Boost?

yes, but the fact is that boost builds, and the program compiles; it seems that this error is raised at runtime, before the real program itself starts, just when the runtime makes some checks before calling it. So it is appearently a runtime problem: perhaps not of the library failing by itself, but not passing a runtime check. So I'm doing this way: I wait still for some hours, for seeing any answer, then I switch it to build-boost.

ok, switched "component" to "build". do I have to do anything else to transfer this bug ?

thanks, Marco

[Vladimir Prus]

I am not entirely sure this is a problem with Boost. For starters, I am not even sure if using Boost with CLR is supposed to work, and if it is supposed to work, I'd imagine Boost shall be build with the same /clr options as the rest of the application.

[Vladimir Prus]

Lacking further discussion to justify this is supposed to work, and there's any problem in the way date_time is built, I am closing this ticket. Please reopen if new information is available.