Thread: [Dev-C++] Memory Leak Checking

Hi Y'all,
 
Has anybody used the objidl.h file and associated IMalloc function?  I'm at a loss to understand how it's supposed to be used, and am trying to find some documentation for it that makes more sense than the Microsoft site documentation. It's part of the Microsoft Component Object Model (COM), but all I'm needing is the memory monitoring functions.  It is included in Dev-Cpp.
 
Thanks!




Alfred P. Reaud
 

If you don't insist on using that specific monitor, then Fluid
Studio's memory manager is an excellent, free, and small libary that's
worked wonders for me.  No changes required, just use normal
allocation techniques for C/C++ source code.

From the website:

Memory Manager (a.k.a. "MMGR")

MMGR is an industrial-strength memory manager for almost any project.

Not only will MMGR probably point out some bugs you never knew you
had, but it is also a great development tool. Among other standard
tracking tools (overruns/underruns, deallocation mismatches, etc.),
MMGR also provides a rich featureset of developer tools. For example,
it allows you to set a breakpoint on an arbitrary allocation, generate
a snapshot report of memory currently in use, etc. You can even ask
MMGR to track how much of your allocated RAM is actually in use
(nothing worse than allocating 64MB of memory just to find that you
only needed 2K. :)

http://www.fluidstudios.com/pub/FluidStudios/MemoryManagers/Fluid_Studios_Memory_Manager.zip

-Josh

On Thu, 24 Feb 2005 19:13:57 -0800 (PST), Alfred P. Reaud
<al...@ya...> wrote:
>  
> Hi Y'all, 
>   
> Has anybody used the objidl.h file and associated IMalloc function?  I'm at
> a loss to understand how it's supposed to be used, and am trying to find
> some documentation for it that makes more sense than the Microsoft site
> documentation. It's part of the Microsoft Component Object Model (COM), but
> all I'm needing is the memory monitoring functions.  It is included in
> Dev-Cpp. 
>   
> Thanks!
> 
>  
>  
> 
> Alfred P. Reaud

I think Alfred forgot to reply to all, so I'm doing him the favour.


---------- Forwarded message ----------
From: Alfred P. Reaud <al...@ya...>
Date: Thu, 24 Feb 2005 22:38:52 -0800 (PST)
Subject: Re: [Dev-C++] Memory Leak Checking
To: Josh Matthews <mrl...@gm...>


 
 
 
 
 
 
Hi Josh, 
  
Thanks for the help!  Currently I'm doing class debugging by units,
piece by bloody piece to find these insidious memory leaks!  This is
recommended in Test Your Classes, a part of Just Say No To Memory
Leaks.
  
I'm using LeakTracer for the leak test.  It's only downside its that
it requires the Perl language to use effectively, though it isn't
required for actual use.  Everything is commented out except the GUI
class.  I've already verified that the GUI constructor/destructor has
no leaks.  Just rechecked it, getting the report:
$ cat leak.out
# starting Thu Feb 24 22:59:03 2005
# memory overrun protection of 4 Bytes
# initializing new memory with 0xAA
# sweeping deleted memory with 0xEE
# aborts on OVERWRITE_MEMORY 
# not thread save; if you use threads, recompile with -DTHREAD_SAVE
# internal buffer now 32768
# finished Thu Feb 24 22:59:03 2005
# total allocation requests:      2 ; max. mem used 1 kBytes
# leak      0 Bytes     :-) 
  
I've got these two macros to help: 
#define zap(x) if (x) { delete(x); x = NULL; }
#define zap_array(x) if (x) { delete[](x); x = NULL;  } 
  
In GUI class declaration, I'm declaring a public pointer to a FLTK
text display buffer:
... 
Fl_Text_Buffer *textbuffer; // Text widget buffer. 
... 
  
In the constructor I'm declaring: 
...
zap( textbuffer )
textbuffer = new Fl_Text_Buffer(1024);
... 
  
In the destructor I'm declaring: 
... 
zap( textbuffer );
... 

In my make_window code I have (and I've put this all over the place,
including trying it as a static declaration at the top of the module &
not using the declaration in the class, in the make_window call, and
in the constructor, which is it's current location.  Nothing changes
other than the machine code address of the leak!):
  
void GUI::make_window ( const HINSTANCE hThisInstance ) { 
... 
statusTextDisplay = new Fl_Text_Display(100, 295, 270, 135, "File
Cleaner Status/Results");
statusTextDisplay->buffer( textbuffer );
... 
} 
  
So I'm creating a pointer to a structure with new, and then I'm
deleting it if that pointer isn't NULL.  Running the program, I have a
4 byte leak at 0x410E40 (among 4 others for a total leak of 68 bytes),
which LeakTracer says isn't in my code.  Using Insight, it's reported
as being D:/Dev-Cpp/include/c++/3.3.1/cmath, line 477.  Fine...
  
At the breakpoint I get the following: 
Breakpoint 2, 0x00410e40 in
Fl_Text_Buffer::add_predelete_callback(void (*)(int, int, void*),
void*) () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
Current language:  auto; currently c++ 
  
With the stack trace being: 
#0  0x00410e40 in Fl_Text_Buffer::add_predelete_callback(void (*)(int,
int, void*), void*) () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
#1  0x00409087 in Fl_Text_Display::buffer(Fl_Text_Buffer*) () at
D:/Dev-Cpp/include/c++/3.3.1/cmath:477
#2  0x00405742 in GUI::make_window(HINSTANCE__*) (this=0x469080,
hThisInstance=0x400000) at FileCleanerPro_Main.cpp:581
#3  0x004062a1 in WinMain (hThisInstance=0x400000, hPrevInstance=0x0,
lpszArgument=0x241f09 "", nFunsterStil=10) at
FileCleanerPro_Main.cpp:794
#4  0x004377ba in main () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477 
  
FileCleanerPro_Main.cpp:581 is statusTextDisplay->buffer( textbuffer ); 
FileCleanerPro_Main.cpp:794 is gui.make_window(hThisInstance); 
  
This only occurs if I'm calling the code to make the window from WinMain: 
... 
gui.make_window(hThisInstance); 
... 
  
Everything else is commented out.  To test the constructor/destructor,
I comment out the above line.  The instantiation of GUI is at the
bottom of the module as GUI gui; and is declared in the header file as
extern GUI gui;
  
My question is then WTF~&*#$!  I'll look over the site you link below,
as I'm also in need of knowing how much memory is actually available
for use before it goes to virtual memory.  The need is in the time
difference between using fputc and fwrite.  fwrite is about 35% faster
(I've run extensive tests on timing, as I'm doing a for-sale
professional version of File Cleaner that uses multi-pass writes to
files to effectuate unrecoverable wiping of data, even with magnetic
force microscopy).  However the speed increase only occurs if you are
actually doing writes to ram vs. hard disk.  I'm resorting to fputc
and fwrite due to inconsistencies that I had using ofstream.  This
application MUST flush to the hard disk every time, or else
confidential and secure wiping (two modes of operation entailing 11
passes and 35 passes respectively) doesn't occur (other than in ram!).
 ofstream wouldn't do that consistently.
  
Thanks for your time, everybody, and apologies for the length of this
post.  I've spent 59+ hours on this so far without satisfactory
solution.  I'm in need of a cigarette or of something much stronger to
burn! ;^)

Josh Matthews <mrl...@gm...> wrote: 
If you don't insist on using that specific monitor, then Fluid
Studio's memory manager is an excellent, free, and small libary that's
worked wonders for me. No changes required, just use normal
allocation techniques for C/C++ source code.
<snip>
http://www.fluidstudios.com/pub/FluidStudios/MemoryManagers/Fluid_Studios_Memory_Manager.zip
<snip>

 
 

Alfred P. Reaud

Hi Josh,
 
Thanks for the help!  Currently I'm doing class debugging by units, piece by bloody piece to find these insidious memory leaks!  This is recommended in Test Your Classes, a part of Just Say No To Memory Leaks.
 
I'm using LeakTracer for the leak test.  It's only downside its that it requires the Perl language to use effectively, though it isn't required for actual use.  Everything is commented out except the GUI class.  I've already verified that the GUI constructor/destructor has no leaks.  Just rechecked it, getting the report:
$ cat leak.out
# starting Thu Feb 24 22:59:03 2005
# memory overrun protection of 4 Bytes
# initializing new memory with 0xAA
# sweeping deleted memory with 0xEE
# aborts on OVERWRITE_MEMORY 
# not thread save; if you use threads, recompile with -DTHREAD_SAVE
# internal buffer now 32768
# finished Thu Feb 24 22:59:03 2005
# total allocation requests:      2 ; max. mem used 1 kBytes
# leak      0 Bytes     :-)
 
I've got these two macros to help:
#define zap(x) if (x) { delete(x); x = NULL; }
#define zap_array(x) if (x) { delete[](x); x = NULL;  }
 
In GUI class declaration, I'm declaring a public pointer to a FLTK text display buffer:
...
Fl_Text_Buffer *textbuffer; // Text widget buffer.
...
 
In the constructor I'm declaring:
...
zap( textbuffer )
textbuffer = new Fl_Text_Buffer(1024);
...
 
In the destructor I'm declaring:
...
zap( textbuffer );
...

In my make_window code I have (and I've put this all over the place, including trying it as a static declaration at the top of the module & not using the declaration in the class, in the make_window call, and in the constructor, which is it's current location.  Nothing changes other than the machine code address of the leak!):
 
void GUI::make_window ( const HINSTANCE hThisInstance ) {
...
statusTextDisplay = new Fl_Text_Display(100, 295, 270, 135, "File Cleaner Status/Results");
statusTextDisplay->buffer( textbuffer );
...
}
 
So I'm creating a pointer to a structure with new, and then I'm deleting it if that pointer isn't NULL.  Running the program, I have a 4 byte leak at 0x410E40 (among 4 others for a total leak of 68 bytes), which LeakTracer says isn't in my code.  Using Insight, it's reported as being D:/Dev-Cpp/include/c++/3.3.1/cmath, line 477.  Fine...
 
At the breakpoint I get the following:
Breakpoint 2, 0x00410e40 in Fl_Text_Buffer::add_predelete_callback(void (*)(int, int, void*), void*) () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
Current language:  auto; currently c++
 
With the stack trace being:
#0  0x00410e40 in Fl_Text_Buffer::add_predelete_callback(void (*)(int, int, void*), void*) () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
#1  0x00409087 in Fl_Text_Display::buffer(Fl_Text_Buffer*) () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
#2  0x00405742 in GUI::make_window(HINSTANCE__*) (this=0x469080, hThisInstance=0x400000) at FileCleanerPro_Main.cpp:581
#3  0x004062a1 in WinMain (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x241f09 "", nFunsterStil=10) at FileCleanerPro_Main.cpp:794
#4  0x004377ba in main () at D:/Dev-Cpp/include/c++/3.3.1/cmath:477
 
FileCleanerPro_Main.cpp:581 is statusTextDisplay->buffer( textbuffer );
FileCleanerPro_Main.cpp:794 is gui.make_window(hThisInstance);
 
This only occurs if I'm calling the code to make the window from WinMain:
...
gui.make_window(hThisInstance);
...
 
Everything else is commented out.  To test the constructor/destructor, I comment out the above line.  The instantiation of GUI is at the bottom of the module as GUI gui; and is declared in the header file as extern GUI gui;
 
My question is then WTF~&*#$!  I'll look over the site you link below, as I'm also in need of knowing how much memory is actually available for use before it goes to virtual memory.  The need is in the time difference between using fputc and fwrite.  fwrite is about 35% faster (I've run extensive tests on timing, as I'm doing a for-sale professional version of File Cleaner that uses multi-pass writes to files to effectuate unrecoverable wiping of data, even with magnetic force microscopy).  However the speed increase only occurs if you are actually doing writes to ram vs. hard disk.  I'm resorting to fputc and fwrite due to inconsistencies that I had using ofstream.  This application MUST flush to the hard disk every time, or else confidential and secure wiping (two modes of operation entailing 11 passes and 35 passes respectively) doesn't occur (other than in ram!).  ofstream wouldn't do that consistently.
 
Thanks for your time, everybody, and apologies for the length of this post.  I've spent 59+ hours on this so far without satisfactory solution.  I'm in need of a cigarette or of something much stronger to burn! ;^)

Josh Matthews <mrl...@gm...> wrote:
If you don't insist on using that specific monitor, then Fluid
Studio's memory manager is an excellent, free, and small libary that's
worked wonders for me. No changes required, just use normal
allocation techniques for C/C++ source code.
<snip>
http://www.fluidstudios.com/pub/FluidStudios/MemoryManagers/Fluid_Studios_Memory_Manager.zip
<snip>









Alfred P. Reaud