[W] MLK: Memory leak of 12288 bytes from 1 block allocated in CAtlAllocator::AddModule(HINSTANCE__ *) [MFC71D.DLL]
CAtlAllocator::AddModule(HINSTANCE__ *) [allocate.cpp:333]
{
ULONG nNewAllocSize = kModuleBatchSize*sizeof( CAtlTraceModule );
void* pNewModules = reinterpret_cast<BYTE *>(pProcess) + pProcess->m_dwFrontAlloc;
=> VirtualAlloc(pNewModules, nNewAllocSize, MEM_COMMIT, PAGE_READWRITE);
pProcess->m_dwFrontAlloc += nNewAllocSize;
for( ULONG iNewModule = 0; iNewModule < kModuleBatchSize; iNewModule++ )
{
Тараканьи бега или в погоне за мемори ликами
хотелось бы услышать о приёмах, методах и софта для борьбы с утечками памяти и её неправильным использованием. конкретные отзывы о различных профайлерах например.
более конкретно -- взял на днях пьюрифай плюс и "отпьюрифаил" на работе один ActiveX компонент. своих дырок нашёл довольно прилично (да и тех, что были до меня оставлены). но самое неприятное, что он показывает ещё около десятка утчек памяти в системных вызовах типа CoCreateInstace, инициализации COM-объекта (ATL'ный) и т.п. вот и возникает резонный вопрос -- или я что-то не так как предусмотрено использую, или это очередные коряги виндовоза? т.к. вопрос "как с этим боротся" задавать бессмысленно до выяснения причин!
более конкретно -- взял на днях пьюрифай плюс и "отпьюрифаил" на работе один ActiveX компонент. своих дырок нашёл довольно прилично (да и тех, что были до меня оставлены). но самое неприятное, что он показывает ещё около десятка утчек памяти в системных вызовах типа CoCreateInstace, инициализации COM-объекта (ATL'ный) и т.п. вот и возникает резонный вопрос -- или я что-то не так как предусмотрено использую, или это очередные коряги виндовоза? т.к. вопрос "как с этим боротся" задавать бессмысленно до выяснения причин!
Дык о каком типе утечки памяти речь? О выходе за пределы массива или просто программа жрет неприлично много памяти?
вот одно из типичных сообщений Purify
т.е. всё-таки new\delete
Код:
т.е. всё-таки new\delete
Ну во-первых майкрософтовские длл-ки пусть майкрософт отлаживает: не царское дело в чужом г... то есть в чужом закрытом коде ковыряться. А во-вторых MFC71D.DLL - это все-таки отладочная версия MFC71.DLL
ну просто забить -- этот вариант от нас никуда не денется :) просто возможно это связано с неправильным использованием чего-либо? хотя, присмотревшись к строкам чуть ниже увидел что-то типа AtrDebugTrace и т.п. то бишь баги в самом отладчике мелкого софта.
ещё меня очень беспокоит вот такая вещь: Message: Assertion failed: pHead->nBlockUse == nBlockUse
в дебаге у меня многие программы после закрытия вываливаются с таким ассёртом. в релизе всё ок (в смысле не видно граблей), а в дебаге этот асёрт вылетает очень стабильно. и знаю, что не только у меня. может кто-то знает что это и из-за чего?
ещё меня очень беспокоит вот такая вещь: Message: Assertion failed: pHead->nBlockUse == nBlockUse
в дебаге у меня многие программы после закрытия вываливаются с таким ассёртом. в релизе всё ок (в смысле не видно граблей), а в дебаге этот асёрт вылетает очень стабильно. и знаю, что не только у меня. может кто-то знает что это и из-за чего?
http://www.rsdn.ru/article/vcpp/leaks.xml -вот статья мож будет интересна...
Такие вещи (утечки памяти) должен ловить любой приличный профайлер, типа того же VTune.
или вот - http://forums.realcoding.net/index.php?showtopic=15141 , может, что нужное найдешь.
Такие вещи (утечки памяти) должен ловить любой приличный профайлер, типа того же VTune.
или вот - http://forums.realcoding.net/index.php?showtopic=15141 , может, что нужное найдешь.
благодарю за ссылки! весьма пользительно
А кто что думает о http://www.deleaker.com ?