Re: [Boost-users] [Boost.Test] reports incorrect memory leak

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-04-14 02:16:49

mike <mboard182 <at> gmail.com> writes:

> 
> An extremely simple piece test, containing just one stack-created 
> object, is causing boost.test to report a memory leak.

Boost.Test doesn't report memory links. It uses Microsoft C runtime library
debug runtime feature. 
 
> I am using boost 1.34.1 compiled in windows using configure, bjam, & 
> msvc90.  I've copied my simple test case illustrating my problem below, 
> and included the output it produces.
> 
> As you can see, boost.test is being used, but the regex is part of 
> microsoft's tr1.  As a note, when I modify it to use boost's regex (with 
> the commented-out changes seen in code), no such errors were reported.

This should point you in right direction. Obviously something in MS
implementation of regex is leaking, or rather is allocating some global
resources which are not cleared before main() exit.
 
> I'd like to say that obviously the SOLE problem lies in MS' beta tr1 
> implementation, but this code is so simple I don't get how that would 
> be.  Also, i believe the actual TR1 impl is from dinkumware and is 
> supposed to be fully release ready (it is just the ms-CLI, etc, 
> integration which leads to the beta designation)...

As I said, I believe this is red herring. Most probably they allocate some
global shared buffers. 
 
> Hopefully someone has more insight into this.  Also, if someone has any 
> tips on how to interpret the memory dump boost.test provides, I'd be 
> interested in learning.

Look for MS C Runtime debug info for more details, but it's pretty trivial:
 
> {208} normal block at 0x00347DD8, 20 bytes long.
> Data: <p-J             > 70 2D 4A 00 15 00 00 00 00 00 00 00 00 00 00 00

208 - allocation number. 
0x00347DD8 - memory address.
20 - memory size
<...>  - dump of the memory in askii
70 ... 00 - dump of the memory in hex.

HTH,

Gennadiy