Memory leaks in VC6 2 line Python 2.1b1 apps?

Tom NoSpam at
Sun Mar 11 17:16:10 CET 2001


The debug CRT can give you this info.
Add the following to your program to enable this feature.  I put it in my
precompiled header.

// For memory debugging (VC++ specific)
// Must come after some STL includes (or conflicts with 'new')
#ifdef _DEBUG
//#include <stdlib.h> // seen this recom., but I don't see why
 // Causes CrtDbg to #define all the crt alloc routines to versions with
more debug info,
 // to replace operator new with one that adds debug info.
 //  (but in a stupid way that doesn't work - so we #define new ourselves
after CrtDbg.h.)
#include <crtdbg.h>
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)

For more info, see the crt docs in MSDN.  There are a number of options.

Let me know if you are using wxWindows - this requires more changes.


"Craig Holman" <craig at> wrote in message
news:98dngs$2cmm$1 at
> I wish that Visual Studio's memory-leak reporter were smart enough to
> display where the leaked blocks of memory were allocated.  It only puts
> pairs of lines like the following :
> {1037} normal block at 0x0079CE80, 39 bytes long.
>  Data: <  y             > 20 EE 79 00 88 85 1F 1E 03 00 00 00 B8 17 20 1E
> The other lines in the annotated dump were added by me.  They contain the
> results of my efforts to figure out where the leaked blocks were
> After each of the pair of lines produced by the memory-leak reporter, I've
> listed my best guess as to what kind of a block was leaked and why, the
> in the Python 2.1b1 source file that I placed a breakpoint at that
> the leaked memory block, and a snapshot of the relevant part of the
> stack at the point that the breakpoint was hit and execution was paused.
> haven't identified where all of the leaked blocks are being allocated yet.
> Hope this helps,
> Craig
> "Owen F. Ransen" <ransen_spam_me_not at> wrote in message
> news:3aa91ea5.645940 at
> > On Fri, 9 Mar 2001 10:28:33 -0600, "Craig Holman"
> > <craig at> wrote:
> >
> > >Greetings,
> > >
> > >I'm afraid that both versions 2.0 and 2.1b1 leak memory for a single
> > >Py_Initialize, Py_Finalize sequence in a
> > >Visual C++ MFC application.
> >
> > Phew! I thought it was just me!  ;)
> >
> > I hope someone understands the rest of your post, I'm too new
> > to Python embedding to help. Also, for some reason, though I
> > did rebuild from source, VC gives me the leak "number" but not
> > the line in the library which caused it.
> >
> >
> > --
> > Owen F. Ransen
> >
> > Home of Gliftic & Repligator Image Generators

More information about the Python-list mailing list