Author Topic: Is this a memory leak?  (Read 10210 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Is this a memory leak?
« Reply #15 on: January 24, 2006, 03:42:12 pm »
When my copy of Code::Blocks is running in debug mode in Visual Studio, it dumps a list of all non-freed objects at exit including size of the allocation and the filename and line number where they were allocated.  :shock: Some feature of wxWidgets that came out in the VS debugger??
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Is this a memory leak?
« Reply #16 on: January 24, 2006, 06:06:54 pm »
Seems I forgot to add the word "opensource" and "free" to it. :lol:

When my copy of Code::Blocks is running in debug mode in Visual Studio, it dumps a list of all non-freed objects at exit including size of the allocation and the filename and line number where they were allocated.  :shock: Some feature of wxWidgets that came out in the VS debugger??

Seems you have noticed it. :) The redefinition of operator new (which thomas likes to ditch very often :P) haves a real and very useful purpose.
And it's only enabled when you are in debug build. But anyways, you can disable it by settings wxUSE_DEBUG_NEW_ALWAYS to 0 in setup.h.

For wxDebugContext to do its work, the new and delete operators for wxObject have been redefined to store extra information about dynamically allocated objects (but not statically declared objects). This slows down a debugging version of an application, but can find difficult-to-detect memory leaks (objects are not deallocated), overwrites (writing past the end of your object) and underwrites (writing to memory in front of the object).


Here's something very useful about the class wxDebugContext:

Quote
wxDebugContext is a class for performing various debugging and memory tracing operations.

This class has only static data and function members, and there should be no instances. Probably the most useful members are SetFile (for directing output to a file, instead of the default standard error or debugger output); Dump (for dumping the dynamically allocated objects) and PrintStatistics (for dumping information about allocation of objects). You can also call Check to check memory blocks for integrity.

Here's an example of use. The SetCheckpoint ensures that only the allocations done after the checkpoint will be dumped.

Code: C++
  1.   wxDebugContext::SetCheckpoint();
  2.  
  3.   wxDebugContext::SetFile("c:\\temp\\debug.log");
  4.  
  5.   wxString *thing = new wxString;
  6.  
  7.   char *ordinaryNonObject = new char[1000];
  8.  
  9.   wxDebugContext::Dump();
  10.   wxDebugContext::PrintStatistics();
  11.