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

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