[Boost-users] [UTF] Strange behaviour of unit_test_examples

From: Mateusz Łoskot (mateusz_at_[hidden])
Date: 2006-03-01 20:32:16

Hi,

I'm trying to understand and use Boost Unit Test Framework
in my project.
First, I did clean checkout from CVS and
I did complete build of Boost using VC++ 8.0.

Next, I started to learn Boost UTF from examples provided.
I created clean project with VC++ 8.0 and added first example
(boost\libs\test\example\unit_test_example_01.cpp).
I compiled and run it without any problems and I got results as expected.

There is only one thing I can't explain why I had not to add
library (e.g. libboost_unit_test_framework-vc80-mt-1_34.lib) to link
with. VC++ did not complain about missing libraries or unresolved
symbols. OK, magic :-)

Then, I tried to run rest of examples, unit_test_example_02.cpp
and unit_test_example_03.cpp, as explained above.
And here comes my problems I noticed with unit_test_example_02
and unit_test_example_03.
When I try to run compiled example from unit_test_example_02.cpp I get
memory leaks detected:

========== unit_test_example_02 - OUTPUT START ====================
D:\temp\bt\Debug>unit_example.exe
Running 1 test case...
d:/temp/bt/example.cpp(20): error in "free_test_function": check 2 == 1
failed
Detected memory leaks!
Dumping objects ->
{196} normal block at 0x003A6500, 16 bytes long.
  Data: <, H          d: > 2C 8D 48 00 01 00 00 00 01 00 00 00 C8 64 3A 00
{195} normal block at 0x003A64C8, 8 bytes long.
  Data: <  H  `: > 0C 8D 48 00 D4 60 3A 00
{194} normal block at 0x003A6318, 52 bytes long.
  Data: <@a:  b: @a:     > 40 61 3A 00 B8 62 3A 00 40 61 3A 00 00 00 01 00
{193} normal block at 0x003A62B8, 52 bytes long.
  Data: <@a: @a:  c:     > 40 61 3A 00 40 61 3A 00 18 63 3A 00 01 00 00 00
{173} normal block at 0x003A6140, 52 bytes long.
  Data: < b:  b:  c:     > B8 62 3A 00 B8 62 3A 00 18 63 3A 00 CD CD CD CD
{172} normal block at 0x003A5E70, 4 bytes long.
  Data: <    > 00 00 01 00
{171} normal block at 0x003A61F8, 24 bytes long.
  Data: < Z: `\:  Z:     > 18 5A 3A 00 60 5C 3A 00 18 5A 3A 00 00 00 01 00
{170} normal block at 0x003A6108, 12 bytes long.
  Data: < a:  a:     > 08 61 3A 00 08 61 3A 00 CD CD CD CD
{169} normal block at 0x003A61A8, 32 bytes long.
  Data: <free_test_functi> 66 72 65 65 5F 74 65 73 74 5F 66 75 6E 63 74 69
{165} normal block at 0x003A6080, 92 bytes long.
  Data: <      H   H     > 01 00 00 00 80 0B 48 00 84 0B 48 00 00 00 01 00
{164} normal block at 0x003A6040, 16 bytes long.
  Data: <P G          `: > 50 F9 47 00 01 00 00 00 01 00 00 00 08 60 3A 00
{163} normal block at 0x003A6008, 8 bytes long.
  Data: <0 G   B > 30 F9 47 00 8C 94 42 00
{162} normal block at 0x003A5C60, 24 bytes long.
  Data: < Z:  Z:  a:     > 18 5A 3A 00 18 5A 3A 00 F8 61 3A 00 01 00 00 00
{161} normal block at 0x003A5BC0, 12 bytes long.
  Data: < [:  [:     > C0 5B 3A 00 C0 5B 3A 00 CD CD CD CD
{160} normal block at 0x003A5C10, 32 bytes long.
  Data: <Unit test exampl> 55 6E 69 74 20 74 65 73 74 20 65 78 61 6D 70 6C
{158} normal block at 0x003A5B20, 116 bytes long.
  Data: <0 H       H   H > 30 1C 48 00 10 00 00 00 88 0B 48 00 8D 0B 48 00
{157} normal block at 0x003A5AE0, 20 bytes long.
  Data: <`Z:  Z: `Z:  QI > 60 5A 3A 00 A0 5A 3A 00 60 5A 3A 00 90 51 49 00
{156} normal block at 0x003A5AA0, 20 bytes long.
  Data: <`Z: `Z:  Z: $RI > 60 5A 3A 00 60 5A 3A 00 E0 5A 3A 00 24 52 49 00
{155} normal block at 0x003A5A60, 20 bytes long.
  Data: < Z:  Z:  Z:     > A0 5A 3A 00 A0 5A 3A 00 E0 5A 3A 00 CD CD CD CD
{154} normal block at 0x003A5A18, 24 bytes long.
  Data: <`\: `\:  a:     > 60 5C 3A 00 60 5C 3A 00 F8 61 3A 00 CD CD CD CD
{152} normal block at 0x003A59D8, 16 bytes long.
  Data: < )W             > 14 29 57 10 03 02 00 00 06 00 00 00 00 00 00 00
{151} normal block at 0x003A5FD0, 8 bytes long.
  Data: <  H     > 90 90 48 00 CD CD CD CD
{150} normal block at 0x003A5FA0, 4 bytes long.
  Data: <  G > 80 FF 47 00
{149} normal block at 0x003A5EA0, 208 bytes long.
  Data: <d:/temp/bt/examp> 64 3A 2F 74 65 6D 70 2F 62 74 2F 65 78 61 6D 70
{147} normal block at 0x003A5E30, 16 bytes long.
  Data: < *W             > CC 2A 57 10 01 02 00 00 06 00 00 00 00 00 00 00
{146} normal block at 0x003A5CD0, 304 bytes long.
  Data: < 4H  5H @5H H5H > FC 34 48 00 0D 35 48 00 40 35 48 00 48 35 48 00
Object dump complete.
========== unit_test_example_02 - OUTPUT END ====================

So, the results are not as expected.
I started to investigate what is going wrong and I only found few posts
in mailing lists archives:

boost::test: expected error leads to failure - why?
http://thread.gmane.org/gmane.comp.lib.boost.user/16580

Unit test FP comparisons - memory leaks in debug
http://thread.gmane.org/gmane.comp.lib.boost.devel/132099

Boost Test Memory Dumping...
http://thread.gmane.org/gmane.comp.lib.boost.user/14119

Unfortunately, those posts do not provide significant help for
my problem.

I also tried to play with --detect_memory_leak=0 parameter but it did
not change results, examples are still leaking.

So, I tried to investigate in other places.
I found there are project files prepared for VC++ 7.1
(\boost\libs\test\build\msvc71_proj)
so I opened solution in VC++ 8.0 and walked through 7.1->8.0
conversion wizard. No errors.

Next, I build test/examples using those project files
and I revealed that unit_test_example_02 and unit_test_example_03 run
without any memory leaks/dump and I get results as expected.

So, I started to look what are the differences between my own project
created from scratch and projects shipped with Boost.
I revealed that UTF examples projects from Boost build
it's own version of
\boost\stage\lib\libboost_prg_exec_monitor-vc71-mt-gd-1_34.lib

NOTE: Here, -vc71- in the library name name is left after
7.1->8.0 project conversion but it does not matter because its
built with VC++ 8.0 in fact.

Hmm, why it does not use UTF library built and installed by bjam?
In my case it is located in
c:\boost-vc-8_0-cvs\lib\libboost_unit_test_framework-vc80-mt-gd-1_34.lib
where c:\boost-vc-8_0-cvs is my BOOST_ROOT.

What's more interesting is that when I use UTF library created with
VC++ project file
(\boost\stage\lib\libboost_prg_exec_monitor-vc71-mt-gd-1_34.lib)
in my own unit_example project (created from scratch) all examples,
especially unit_test_example_02 and unit_test_example_03, run without
any memory leaks/dump and I get results as expected.

As I revealed during next steps those libraries (the first one built
with VC++ 8.0 project and the second built with bjam) are different in
size in more than 3 MB.

I tried to compare compilation/linking options used by bjam to build UTF
library with options I use in VC++ 8.0 projects but it seems I'm not
well familiar with jam files so I could not found any CFLAGS/CXXFLAGS or
similar stuff.

The question I'd like to ask is am I doing something wrong?
What causes memory leaks dump when I try to use UTF library(ies) created
by bjam? I suppose there is some magic switch.

Also, I tried to debug UTF example 02 and 03 when they dumped memory
leaks and I revealed that there are exceptions thrown in lines supposed
to be catched by Boost Test Framework:

- unit_test_example_02.cpp

// Lines near 24-25
int* p = (int*)0;
BOOST_CHECK( *p == 0 );

Here is output message:

First-chance exception at 0x0042cfb2 in bt.exe: 0xC0000005: Access
violation reading location 0x00000000.
Unhandled exception at 0x0042cfb2 in bt.exe: 0xC0000005: Access
violation reading location 0x00000000.

- unit_test_example_03.cpp

// Line near 25
// reports 'unknown location(0): fatal error i
// "force_division_by_zero": integer divide by zero'
i = i / j;

Here is output message:

First-chance exception at 0x0042f295 in bt.exe: 0xC0000094: Integer
division by zero.
Unhandled exception at 0x0042f295 in bt.exe: 0xC0000094: Integer
division by zero.

Huh! That's the end of my long story :)
I'd be very thankful for any help how to solve this problem, especially
with "original" UTF library created by bjam. How to make it working?

Please, be placable as I'm a Boost.Test newbie. I searched through
Boost.Test docs and lists archives but I still can not solve my problem.

Thanks in advance for your help
Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net