Visual C ++, MFC Application, No Malloc и т. Д. Вообще: что может вызвать утечку памяти?

Question

Visual C ++, MFC Application, No Malloc и т. Д. Вообще: что может вызвать утечку памяти?

0

Начинающий от C++.

Я потратил 8+ часы, пытаясь найти помощь Google здесь.

(добавлено: я установил пробную версию PurifyPlus, но мое приложение не запускает "внутри" по какой-либо причине).

У меня есть приложение MFC с постоянной утечкой памяти.

Существует ряд потоков как: DWORD WINAPI WorkThread (LPVOID lParam), каждый из которых вызывает потоки как: void TradeLogic (CIBTraderDlg * pDlg) на таймере.

Появится диалоговое окно с элементами управления ListView.

Нет никаких вызовов "malloc" или "calloc" в любом месте приложения. (поиск включает полный API). Существует один "новый" сокет, который выполняется только один раз при запуске программы. Динамических распределений нет с "новым". Существует одно чтение из файла, которое происходит только один раз, когда запускается программа.

Но есть утечка памяти, которая сохраняется, до бесконечности. (Примерно 4 Кбайта каждые 15 секунд, не совсем одинаковые)

Моя программа не полностью запускается в режиме отладки. Диалог появляется, но он не выполняет никаких вызовов на удаленное время сервера, а не события, которые отключают это (включая обновление списков просмотров).

Тем не менее, работая в "Отлаге" настолько квалифицированной, когда я нажимаю кнопку "Выход", вывод Debug показывает сообщения CRT, как в документации, но они не являются откровенно полезными, поскольку утечки вообще не произошло (они предлагают "новое" для розетка может протекать, но опять же, розетка открывается только один раз). Taskmgr подтверждает отсутствие утечки в этом ограниченном режиме.

Итак, я последовал за MSDN и попробовал следующий код в последовательности "Выход":

HANDLE hLogFile;
hLogFile = CreateFile("c:\\log.txt", GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
_CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_ERROR, hLogFile);

_RPT0(_CRT_ERROR,"file message\n");
_CrtDumpMemoryLeaks();
CloseHandle(hLogFile);
exit(0);

и запускал программу в обычном режиме. Но когда я нажимаю "Выход", я получаю текстовое "сообщение с файлом", и ни один из результатов CRT вообще не проверяется.

Может ли кто-нибудь указать мне, где я могу найти код для проблем?

cjv 27 дек. 2014, в 20:14

Источник

0

У вас есть указатели, умные указатели, темы? Не можете ли вы использовать детектор утечки памяти (Purify, Valgrind, ...)
Basile Starynkevitch 27 дек. 2014, в 19:11
0

Я скачал Purify, но мое приложение почему-то не запускается внутри него.
cjv 27 дек. 2014, в 19:16
0

Кстати, если бы вы могли написать свое приложение для Linux (например, используя Qt ..., которое также может быть скомпилировано в Windows), это могло бы быть проще - потому что в Linux есть много инструментов, которые могут помочь в этом.
Basile Starynkevitch 27 дек. 2014, в 19:18
0

Вы инициализируете каждую вещь (в частности, инициализируете каждое поле внутри всех ваших конструкторов)?
Basile Starynkevitch 27 дек. 2014, в 20:04
0

Я инициализировал все числовые массивы в {0 / 0.00} после объявления
cjv 27 дек. 2014, в 20:43
0

Я думал о полях внутри вашего class -es ... Кроме того, вы включили все предупреждения в вашем компиляторе?
Basile Starynkevitch 27 дек. 2014, в 20:45
0

1) Вы можете протестировать некоторые части кода в отдельном приложении, чтобы уменьшить подозрительный код, где происходит утечка, до одного блока / функции. 2) Стандартные компоненты из некоторых библиотек также могут иметь утечки памяти, особенно если используются нестабильные версии.
John_West 27 дек. 2014, в 21:08
0

Спасибо, Джон. Я идиот, чтобы не думать об этом. Я просто пройду и закомментирую компоненты каждой основной функции, пока не найду ту, которая ее вызывает.
cjv 27 дек. 2014, в 21:39
0

PS Кажется, это функция для получения времени с удаленного сервера. Функция вызывается сокетом, поэтому я не могу редактировать исходный код.
cjv 27 дек. 2014, в 21:57
0

Скачайте Application Verifier и запустите ваше приложение под ним.
rrirower 30 дек. 2014, в 16:35
0

Проверьте с Deleaker, но не забудьте отключить все фильтры, потому что - сюрприз! - утечка может произойти и в библиотеках системы.
Artem Razin 02 янв. 2015, в 18:19
0

Я не могу комментировать наверняка, не имея исходного кода, но я надеюсь, что вы не смешиваете диалоги MFC с рабочими потоками?
gast128 27 окт. 2015, в 10:39

Показать ещё 10 комментариев

Теги:

c++

memory-leaks

mfc

1 ответ

Ещё вопросы

У вас есть указатели, умные указатели, темы? Не можете ли вы использовать детектор утечки памяти (Purify, Valgrind, ...)
Я скачал Purify, но мое приложение почему-то не запускается внутри него.
Кстати, если бы вы могли написать свое приложение для Linux (например, используя Qt ..., которое также может быть скомпилировано в Windows), это могло бы быть проще - потому что в Linux есть много инструментов, которые могут помочь в этом.
Вы инициализируете каждую вещь (в частности, инициализируете каждое поле внутри всех ваших конструкторов)?
Я инициализировал все числовые массивы в {0 / 0.00} после объявления
Я думал о полях внутри вашего class -es ... Кроме того, вы включили все предупреждения в вашем компиляторе?
1) Вы можете протестировать некоторые части кода в отдельном приложении, чтобы уменьшить подозрительный код, где происходит утечка, до одного блока / функции. 2) Стандартные компоненты из некоторых библиотек также могут иметь утечки памяти, особенно если используются нестабильные версии.
Спасибо, Джон. Я идиот, чтобы не думать об этом. Я просто пройду и закомментирую компоненты каждой основной функции, пока не найду ту, которая ее вызывает.
PS Кажется, это функция для получения времени с удаленного сервера. Функция вызывается сокетом, поэтому я не могу редактировать исходный код.
Скачайте Application Verifier и запустите ваше приложение под ним.
Проверьте с Deleaker, но не забудьте отключить все фильтры, потому что - сюрприз! - утечка может произойти и в библиотеках системы.
Я не могу комментировать наверняка, не имея исходного кода, но я надеюсь, что вы не смешиваете диалоги MFC с рабочими потоками?

Jim Beveridge · Answer 1 · 2016-06-22T20-49-00.000Z

Вы можете попробовать эту библиотеку, чтобы легко обнаружить утечки, но я предполагаю, что проблема в том, что Windows выделяет память, поэтому это не поможет.

https://vld.codeplex.com/

Затем проверьте свое приложение только с одним рабочим потоком, чтобы убедиться, что у вас нет условий гонки. Если он работает только с одним рабочим потоком, то у вас многопоточность.

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

Если вы пытаетесь обновить ListView из нескольких потоков, тогда у вас возникнут проблемы. Элементы управления Windows, такие как ListView, запускаются только в основном потоке, поэтому все рабочие потоки блокируют, обновляя ListView.