Boost logo

Boost Users :

From: Christian Henning (chhenning_at_[hidden])
Date: 2005-08-25 12:49:08


Here are some statistics of
void* new_critical_section()
and
void delete_critical_section(void* mutex)

inside mutex.inl .

Basically I put a breakpoint in both functions. The order of calls
until I close my application is like:

(1) new_critical_section -> new at 0x003265e4
(2) new_critical_section -> new at 0x7c227dce
(3) delete_critical_section -> delete at 0x00327840
(4) new_critical_section -> new at 0x00327a28
(5) delete_critical_section -> delete at 0x00326650

The first thing is: the number of calls to new_critical_section() is
equal to the number of calls to delete_critical_section(). That
shouldn't be, I suppose.

Also, the addresses of "new at" and "delete at" are never the same. I
suppose that shouldn't be, as well.

Now to my memory leaks output:

Detected memory leaks!
Dumping objects ->
{196} normal block at 0x00327B08, 24 bytes long.
 Data: < > 18 AF 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{195} normal block at 0x00327A28, 8 bytes long.
 Data: < {2 > 08 7B 32 00 01 CD CD CD
Object dump complete.

The second leak ( object no: 195 ) is cleary the memory that was
allocated in (4) , see statistics. This memory is never deallocated.
So this leak is correct. A mutex, by the way, is 8 bytes on my
machine. Also, the three "CD"'s make me little worried. "CD" usually
means not initialized.

The first leak is a little more mysterious. Since I don't to who the
memory belongs to. I will try to figure this out a little more.

Any ideas someone?
Christian


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net