Q: BOOST.TEST VC7 mt gd worked on 1.30, fails on 1.31
Hello, I just wanted to ask about your experience with the latest (1.31) Boost.Test module. I had several unit tests written with Boost 1.30, and they worked fine. Now I upgraded to 1.31 and the unit test fails in a weird way: It seems to crash while DEALLOCATING the unit tests themselves. Call stack shows it fails on an ASSERT in <xmemory> void deallocate( pointer _Ptr, size_type ). Debugger shows that _ptr points to one of my unit test functions. I am linking with libboost_unit_test_framework-vc7-mt-gd-1_31.lib, libboost_date_time-vc7-mt-gd-1_31.lib, and xerces-c_2.lib (among others). Code generation: Multi-threaded Debug (/MTd). Any help would be appreciated... Thanks in advance.
"Dan Dimerman" <dimerman@netvision.net.il> wrote in message news:cn9v8p$ubb$1@sea.gmane.org...
Hello, I just wanted to ask about your experience with the latest (1.31) Boost.Test module. I had several unit tests written with Boost 1.30, and they worked fine. Now I upgraded to 1.31 and the unit test fails in a weird way:
It seems to crash while DEALLOCATING the unit tests themselves. Call stack shows it fails on an ASSERT in <xmemory> void deallocate( pointer _Ptr, size_type ). Debugger shows that _ptr points to one of my unit test functions.
I am linking with libboost_unit_test_framework-vc7-mt-gd-1_31.lib, libboost_date_time-vc7-mt-gd-1_31.lib, and xerces-c_2.lib (among others). Code generation: Multi-threaded Debug (/MTd).
Any help would be appreciated... Thanks in advance.
Unfortunately information you gave is not enough for any meaningful analysis. Crash during deallocation indicate essentially some kind of memory corruption, which may be caused by anything that was invoked before. If you suspect that it is Boost.Test responsibility I would recommend to start eliminating external dependencies and step by step bring it to the minimal example that reveal an issue. Let me know if you get any further. Gennadiy.
participants (2)
-
Dan Dimerman -
Gennadiy Rozental