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

[Josh M. <mrl...@gm...>]

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