1

i've been working on a C++ project for some time now in VS 2008. Until recently, upon terminating my application the output window would show if i had any memory leaks. however, a few days ago i noticed it stopped showing this valuable information. i also tried throwing some printf() around, but the output window isn't showing that either.

i'm guessing i changed a preference somewhere, but i can't seem to find it. all the output shows now is which dll's it has loaded/unloaded. any ideas?

thanks, mike

MPelletier
  • 16,256
  • 15
  • 86
  • 137
mike
  • 536
  • 1
  • 6
  • 16
  • Are you sure the Output Window isn't set to display the build output, as opposed to the debug output? – Adam Maras Sep 20 '11 at 02:16
  • yup, it's definitely set to "Show output from Debug" – mike Sep 20 '11 at 02:31
  • A co-worker had this identical issue with VS 2008 C++. It "fixed itself" a week ago, we have no idea how/what fixed it. He was getting all the debug output (e.g. symbols loading, traces, etc.), just not any of the memory leak output by the dbg_heap routines. Just wanted you to know that you're not imagining things. – franji1 Sep 20 '11 at 03:32
  • lol, thanks franji1...always good to know :) – mike Sep 20 '11 at 03:59

1 Answers1

0

From my own experience, the memory leak output gone missing can be due to different reasons. to summarize the most important ones:

  1. Changes in the source code that:

    • disable memory leak reporting (i.e. using _CrtSetDbgFlag)
    • install custom report hooks (see _CrtSetReportHook, _CrtSetReportHook2)
    • redirect the output to a file (see CrtSetReportMode
    • changes in the source code that lead to silent "crashes" on application termination - the application silently terminates without any indication of a problem before reaching the point where the memory leaks are reported (as improbable this might seem I had this once).
  2. Settings in the development environment cause the output to be redirected to another window. One possibility would be: Tools \ Options \ Debugging \ General \ Redirect all Output Window text to the Immediate Window (the fifth from bottom). Probably other possibilities exist here.

I guess one possibility to rule out point 2 would be to create a simple console application in the lines of (main.cpp):

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#ifndef DEBUG_NEW
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif

int _tmain(int argc, _TCHAR* argv[])
{
    int nOldState = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
    _CrtSetDbgFlag(nOldState | _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

    int *pInt = new int[100];
    return 0;
}

If running this application correctly outputs memory leaks then unfortunately you are probably in case 1

Of course I ruled out the obvious things why the output could be gone (some of them already mentioned in the comments).

ds27680
  • 1,993
  • 10
  • 11
  • thanks for the info ds27680. i ran that sample program you posted, and it does output leaks, so i guess it's not a visual studio issue. you mentioned it's possible my app is exiting before the debug info is printed. do you have any more information on how that could happen? also, if it makes a difference, i'm writing a directx application, not a console app. – mike Sep 24 '11 at 03:44
  • @mike Well the best way to debug this would be to place a breakpoint in the CRT sources (i.e. one good place would be crtlib.c in the __CRTDLL_INIT function on the "else if ( dwReason == DLL_PROCESS_DETACH ) {" branch, right before #ifdef _DEBUG /* Dump all memory leaks */ if (_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) & _CRTDBG_LEAK_CHECK_DF) { _CrtSetDumpClient(NULL); __freeCrtMemory(); _CrtDumpMemoryLeaks(); } #endif /* _DEBUG */ – ds27680 Sep 30 '11 at 12:43
  • @mike From that breakpoint debug down uand enter _CrtDumpMemoryLeaks(); (if the function is called). If not then it probably means that some code unsets the _CRTDBG_LEAK_CHECK_DF flag somewhere. – ds27680 Sep 30 '11 at 12:45