Имеется MFC-приложение, и dll (не MFC). В этой dll определен класс
class CSplashScreen
{
public: // ....
private:
static std::map<HWND, CSplashScreen*> s_thisMap;
};
В основном приложении создается экземпляр этого класса (на стеке), живет и умирает спокойно.
Но Visual С++ рапортует об утечках памяти. (О том, что виноват именно этот класс, нашел через _CrtSetBreakAlloc).
Предполагаю, что такая глобальная переменная просто разрушается
после рапорта о возможных утечках, и поэтому кажется, что map недоосвободил свои данные.
Но что можно сделать (кроме как забить)? Может, как-то повлиять на линкер и порядок выгрузки модулей?
dmitry_npi wrote:
> Но что можно сделать (кроме как забить)? Может, как-то повлиять на
> линкер и порядок выгрузки модулей?
Либо забить, либо сказать контроллеру мемори ликов, что эта память
правильная (не помню как и можно ли), либо не выделять память
средствами MSVCRT для этих объектов (использовать WinAPI VirtualAlloc или
как их там + placement new).
Но всё из этого не всегда возможно, кроме первого.
Posted via RSDN NNTP Server 2.1 beta
Здравствуйте, MasterZiv, Вы писали:
MZ>Либо забить, либо сказать контроллеру мемори ликов, что эта память
MZ>правильная (не помню как и можно ли), либо не выделять память
MZ>средствами MSVCRT для этих объектов (использовать WinAPI VirtualAlloc или
MZ>как их там + placement new).
MZ>Но всё из этого не всегда возможно, кроме первого.
О да
Именно невозможно, так как память "утекает" из реализации std::map.
Причем, это было не всегда. Что-то я игрался с проектами в солюшене, и оно появилось.
Здравствуйте, dmitry_npi, Вы писали:
MZ>>Либо забить, либо сказать контроллеру мемори ликов, что эта память
MZ>>правильная (не помню как и можно ли), либо не выделять память
MZ>>средствами MSVCRT для этих объектов (использовать WinAPI VirtualAlloc или
MZ>>как их там + placement new).
MZ>>Но всё из этого не всегда возможно, кроме первого.
_>О да
_>Именно невозможно, так как память "утекает" из реализации std::map.
А что удивительного? Если потеряется объект, содержащий в себе std::map, часть из утечек будет показывать на потроха std::map
_>Причем, это было не всегда. Что-то я игрался с проектами в солюшене, и оно появилось.
Во-первых, надо поставить бряку в деструктор вашего CSplashScreen, и убедиться, что он действительно освобождается. Во-вторых (если деструктор отрабатывает), поставить бряку в _CrtDumpMemoryLeaks и посмотреть, откуда и сколько раз она вызывается. Потом постараться разобраться, что именно пошло не так — может 2 копии MFC в памяти оказались, может еще какие косяки. Что касается первоначального вопроса про порядок выгрузки модулей, то поменять его (в отладочных целях) можно, добавив лишнюю зависимость между используемыми dll (пропатчив некоторые из этих Dll), но это в вашем случае вряд ли пригодится, такой фокус более полезен при использовании сторонних инструментов для поиска утечек.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
