Я пытаюсь найти утечки в моей программе, которая основана на Ogre3D. Я использую следующие определения в моем коде для «нового» чего-либо, чтобы в дальнейшем программа могла обнаружить и сообщить о любой утечке.
#ifdef _DEBUG
#include <crtdbg.h>
#define MyFW_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)
#define MyFW_DELETE delete
#else
#define MyFW_NEW new
#define MyFW_DELETE delete
#endif
Это работает хорошо и предупреждает меня о любых утечках, пока я «новенький», используя MyFW_NEW (если кому-то интересно, почему у меня есть определение для удаления, это просто для полноты и согласованность. Когда я удаляю что-то, что было обновлено с помощью MyFW_NEW, я хочу удалить это с помощью MyFW_DELETE).
Проблема в том, что он обнаруживает утечки в Ogre (неважно, присутствуют ли они или обнаруживает ложные утечки), и выводит множество утечек в указанный мной файл, и их очень много (в основном повторяется), что Visual Studio зависает в течение хороших 10 минут, что недопустимо. Утечки из моего фреймворка теряются примерно через сто утечек из библиотек, от которых зависит мой фреймворк. Более того, он не дает мне номер строки или файл, который отвечает за утечку. Я точно знаю, что утечки не происходят из моего фреймворка, так как я пытался закомментировать все, кроме нескольких основных функций Ogre, которые приводят к этим утечкам (выходные данные приведены ниже).
Если бы я предположил, что это ложные утечки (даже если они настоящие утечки, я должен предположить это, поскольку я не могу изменить источник в Ogre), есть ли способ отфильтровать дамп, чтобы показать утечки только из моего кода?
Спасибо!
РЕДАКТИРОВАТЬ: я забыл поставить вывод из обнаружения утечки (я ставлю только несколько, так как их много)
Обнаружены утечки памяти! Сброс объектов
-> {2123} нормальный блок в 0x036073A8, длиной 32 байта. Данные: 69 6D 61 67 69 6E 61 74 69 6F 6E
20 74 65 63 68
{355} нормальный блок в 0x008CB2B8, 140
длинные байты. Данные:
94 0B 61 01 00 00 00 00 CD CD CD CD 00
00 00 00
{351} нормальный блок в 0x008CB058, 12
длинные байты. Данные: 58
B0 8C 00 58 B0 8C 00 CD CD CD CD
{350} нормальный блок в 0x008C4EB8, 12
длинные байты. Данные: B8
4E 8C 00 B8 4E 8C 00 CD CD CD CD
{349} нормальный блок в 0x008CAF78, 160
длинные байты. Данные: <, d x d>
20 2C 05 64 CD CD CD CD 78 E8 04 64 CD
CD CD CD
{348} нормальный блок в 0x008CAF08, 48
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{347} нормальный блок в 0x008CAE98, 48
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{346} нормальный блок в 0x008CAE28, 48
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{345} нормальный блок в 0x008CADB8, 48
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{344} нормальный блок в 0x008CAD58, 32
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{343} нормальный блок в 0x008CACF8, 32
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{342} нормальный блок в 0x008CAC88, 48
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{341} нормальный блок в 0x008CAC28, 32
длинные байты. Данные:
4F 67 72 65 2F 53 68 61 64 6F 77 45 78
74 72 75
{340} нормальный блок в 0x008CAB38, 176
длинные байты. Данные:
73 74 72 75 63 74 20 56 53 5F 4F 55 54
50 55 54
{339} нормальный блок в 0x008CA808, 752
длина байта.