Утечки памяти SDL и Visual Leak Detector - PullRequest
Новая
       18

Утечки памяти SDL и Visual Leak Detector

4 голосов
/ 24 октября 2011

Хорошо, поэтому я думаю, что моя программа может иметь утечку памяти.Это приложение SDL, и оно кажется слишком большим, чтобы я мог вручную определить утечку.Я искал Windows, эквивалентный Valgrind (я использую Windows 7 x64 и использую Visual Studio 2010), и в итоге наткнулся на Visual Leak Detector .К сожалению, похоже, что он не хочет генерировать вывод.

Я настроил другой проект, пустое консольное приложение, и настроил VLD так же, как в моем приложении SDL.После запуска программы VLD работал отлично и улавливал каждую утечку памяти, которую я в нее бросал.Но в приложении SDL оно просто выводит «Visual Leak Detector версии 2.2 установлен».в начале сеанса отладки и ничего больше, даже когда я намеренно создал утечку памяти прямо в главной функции.

Самое близкое, что я могу сказать, это может быть связано с прикосновением SDL к точке входа в программу,Но это только предположение.Есть ли способ заставить VLD работать с SDL?

Ответы [ 2 ]

2 голосов
/ 22 декабря 2011

Вы можете попробовать deleaker. Это мощный инструмент для устранения утечек памяти.

0 голосов
/ 22 июня 2012

У меня была похожая проблема с использованием библиотеки SDL.Однако в моем случае я пытался использовать обнаружение утечек памяти по умолчанию в Visual Studio 2010, поскольку не хотел использовать стороннюю библиотеку / приложение.

Исправление проблемы

Еслипосле всех необходимых включений, определений и вызовов функций вы все еще не видите распечатанных утечек памяти, возможно, ваша библиотека времени выполнения настроена неправильно.

Двойная проверка, есть ли у вас отладочная версия библиотеки времени выполнения вместо не отладочной (/ MT и /MD).

Многопоточная отладка (/ MTd)

Многопоточная DLL отладки (/ MDd)

Компилятор определяет _DEBUG, когда вы указываете параметр / MTd или / Mdd.Эти параметры указывают отладочные версии библиотеки времени выполнения C. См. Справочник _DEBUG MSDN

Таким образом, символ _DEBUG должен быть определен для включения кода CRT.

[...] Когда _DEBUGне определено, вызовы _CrtSetDbgFlag удаляются во время предварительной обработки [...]. См. Справочник MSDN

Так что сборки отладочной версии недостаточно для определения _DEBUG.

Это то, что вы обычно не делаетеЯ не могу измениться в обычном проекте, но следование руководству по SDL может привести вас к тому, что я был.

Надеюсь, это поможет кому-то еще или даже вам.

ПодробнееПодробности ниже

Я следил за страницей MSDN , чтобы включить обнаружение утечек памяти из коробки с VS 2010.

После объявления этих 

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

Я включил их в свой код и вставил преднамеренную утечку памяти 

int main( int argc, char* args[] )
{
    _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    _CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

    int *pArray = (int*)malloc(sizeof(int) * 24); // Memory not freed

    return 0;
}

Ничего не было распечатано.

Итак, я посмотрел на сборку, и она совершенно не генерировала код CRT, как вы можете видеть: 

int main( int argc, char* args[] )
{
012932F0  push        ebp  
012932F1  mov         ebp,esp  
012932F3  sub         esp,0CCh  
012932F9  push        ebx  
012932FA  push        esi  
012932FB  push        edi  
012932FC  lea         edi,[ebp-0CCh]  
01293302  mov         ecx,33h  
01293307  mov         eax,0CCCCCCCCh  
0129330C  rep stos    dword ptr es:[edi]  
    _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    _CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG ); // Nothing in both case!

    int *pArray = (int*)malloc(sizeof(int) * 24);
0129330E  mov         esi,esp  
01293310  push        60h  
01293312  call        dword ptr [__imp__malloc (129E4CCh)]  
01293318  add         esp,4  
0129331B  cmp         esi,esp  
0129331D  call        @ILT+580(__RTC_CheckEsp) (1291249h)  
01293322  mov         dword ptr [pArray],eax

Затем я понял, что символ _DEBUG, вероятно, не получалопределены.

...