Dinkumware STL, MFC and memory leak

[blugus]

Hi Guys,

I've been try to use Dinkum STL library.

It workes well first, but report memory leak in MFC Debug Mode.

I use Dinkum Unabridged Library for VC++ V4.02, MSVC6, WIN2000 SERVER.

I made a dialog based program by MSVC6, inserted simple code to use
Dinkum STL Library, and added simple code like this.

// TODO: Add extra initialization here
std::list<int> *mylist = new std::list<int>;
mylist->push_back(1);
mylist->push_back(2);
mylist->clear();
delete mylist;


And I got memory leak message like this.

Detected memory leaks!
Dumping objects ->
{70} normal block at 0x003447F0, 200 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Object dump complete.
The thread 0x10F4 has exited with code 0 (0x0).
The program 'D:\zzzzzzzzzzzzz\Debug\zzzzzzzzzzzzz.exe' has exited with
code 0 (0x0).

I tested more complicate program, and got more leaks message.

Is a bug of Dinkum STL or MSVC6 or misuse?


blugus.

 

[Andre Kostur]

(e-mail address removed) (blugus) wrote in

Hi Guys,

I've been try to use Dinkum STL library.

It workes well first, but report memory leak in MFC Debug Mode.

I use Dinkum Unabridged Library for VC++ V4.02, MSVC6, WIN2000 SERVER.

I made a dialog based program by MSVC6, inserted simple code to use
Dinkum STL Library, and added simple code like this.

// TODO: Add extra initialization here
std::list<int> *mylist = new std::list<int>;
mylist->push_back(1);
mylist->push_back(2);
mylist->clear();
delete mylist;


And I got memory leak message like this.

Detected memory leaks!
Dumping objects ->
{70} normal block at 0x003447F0, 200 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Object dump complete.
The thread 0x10F4 has exited with code 0 (0x0).
The program 'D:\zzzzzzzzzzzzz\Debug\zzzzzzzzzzzzz.exe' has exited with
code 0 (0x0).

I tested more complicate program, and got more leaks message.

Is a bug of Dinkum STL or MSVC6 or misuse?

There is insufficient (OK, rather too much) information to determine.
(Welcome to comp.lang.c++, we don't care about MFC or Dialogs. Neither
are Standard C++). First, you are concerned with STL. OK, limit it to
only the STL portion. Try:

#include <list>

int main() {
std::list<int> * mylist = new std::list<int>;
mylist->push_back(1);
mylist->push_back(2);
mylist->clear();
delete mylist;
return 0;
}


And see if that leaks. If you only have that code and it still leaks,
then you may have an issue with your STL library.

 

[P.J. Plauger]

I've been try to use Dinkum STL library.

It workes well first, but report memory leak in MFC Debug Mode.

I use Dinkum Unabridged Library for VC++ V4.02, MSVC6, WIN2000 SERVER.

I made a dialog based program by MSVC6, inserted simple code to use
Dinkum STL Library, and added simple code like this.

// TODO: Add extra initialization here
std::list<int> *mylist = new std::list<int>;
mylist->push_back(1);
mylist->push_back(2);
mylist->clear();
delete mylist;


And I got memory leak message like this.

Detected memory leaks!
Dumping objects ->
{70} normal block at 0x003447F0, 200 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Object dump complete.
The thread 0x10F4 has exited with code 0 (0x0).
The program 'D:\zzzzzzzzzzzzz\Debug\zzzzzzzzzzzzz.exe' has exited with
code 0 (0x0).

I tested more complicate program, and got more leaks message.

Is a bug of Dinkum STL or MSVC6 or misuse?

We know of no leaks, but more than one leak detector reports
false positives. The usual cause is the delayed release of
memory for certain lazy evaluations. The release occurs *after*
the leak detector makes its report.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Samuele Armondi]

Hi Guys,

I've been try to use Dinkum STL library.

It workes well first, but report memory leak in MFC Debug Mode.

I use Dinkum Unabridged Library for VC++ V4.02, MSVC6, WIN2000 SERVER.

I made a dialog based program by MSVC6, inserted simple code to use
Dinkum STL Library, and added simple code like this.

I tested more complicate program, and got more leaks message.

Is a bug of Dinkum STL or MSVC6 or misuse?


blugus.

Its worth remembering that some libraries overload the new operator... This
could be causing some problems, so it might be worth checking through your
header files. If there is some overloaded operator causing the problem, try
to change the order of the includes to correct the problem.
HTH,
S. Armondi

 

[Arno Huetter]

Hi there,

as you already know the allocation order number (70), why don't you
just set a breakpoint there (_CrtSetBreakAlloc())?

You might also want to consider applying a professional tool for
memory leak and corruption detection, like Compuware's BoundsChecker
(this one also finds out about destroyed stackframes, missing thread
synchronization, and more).

Kind regards,
Arno Huetter

 

[blugus]

First of all, Sorry for misuse board.

I tried to post the message in comp.lang.c++.moderated, but I made a
mistake.


I try to set a breapoint by _CrtSetBreakAlloc().

But breakpoint doesn't work, if memory leaks were generated by Dinkum
LIB.

Of course, other breakpoints work if memory leaks were generated by my
own code.

I don't know why breakpoints doesn't work if it related with Dinkum
LIB.




I make a new simple dialog based program, not use Dinkum LIB.
And I try to set more breakpoint like this.

_CrtSetBreakAlloc(1){,,msvcrtd.dll}
_CrtSetBreakAlloc(2){,,msvcrtd.dll}
_CrtSetBreakAlloc(3){,,msvcrtd.dll}
_CrtSetBreakAlloc(4){,,msvcrtd.dll}
...................................
_CrtSetBreakAlloc(68){,,msvcrtd.dll}


but 1~48 breakpoints does not works.

Because the global variable _crtBreakAlloc does not set before
_lRequestCurr become 49 in DBGHEAP.C file.

The code is like this.


-----------------------------------------------------------
void * __cdecl _heap_alloc_dbg(
size_t nSize,
int nBlockUse,
const char * szFileName,
int nLine
)
{
long lRequest;
size_t blockSize;
int fIgnore = FALSE;
_CrtMemBlockHeader * pHead;

/* verify heap before allocation */
if (_crtDbgFlag & _CRTDBG_CHECK_ALWAYS_DF)
_ASSERTE(_CrtCheckMemory());

lRequest = _lRequestCurr;

/* break into debugger at specific memory allocation */
if (lRequest == _crtBreakAlloc)
_CrtDbgBreak(); // <----- breakpoint ..
-----------------------------------------------------------

If I use Dinkum LIB, the memroy leak occur in DEBUG mode.
And the code line number, which make memory leak, is not displayed in
Output Window.

If the line number is not displayed, the _CrtSetBreakAlloc() function
doesn't work.

I think that Dinkum LIB code tries to allocate memory before debug
code is initialized.
So the code number, which generate memory leak, doesn't displayed.
And the breakpoint, which relate with it, doesn't work.

Maybe the problem is about environments.

I use a Korean OS, Korean MSVC6.

I don't try to test Dinkum LIB in English OS.

After the environment test, I will post about it.