При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
Detected memory leaks!
Dumping objects ->
{2003} normal block at 0x02742700, 12 bytes long.
Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
{2002} normal block at 0x027426B8, 12 bytes long.
Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
М.б. как-то использовать RTTI?
М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

Здравствуйте, hypnotic, Вы писали:

H>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>Detected memory leaks!
H>Dumping objects ->
H>{2003} normal block at 0x02742700, 12 bytes long.
H>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>{2002} normal block at 0x027426B8, 12 bytes long.
H>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>М.б. как-то использовать RTTI?
H>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

В VC 6++ надо кликать на какую-то из этих строчек, при этом в редакторе показывают код new, где этот объект создается.
Это нормально работает, если файл генерируется ClassWizardом, насколько я понимаю, ответственными за это поведенеие является то, что он дописывает вначале этого файла:

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

Может, есть еще какие-то нюансы, а в общертах так.

Здравствуйте, hypnotic, Вы писали:

H>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>Detected memory leaks!
H>Dumping objects ->
H>{2003} normal block at 0x02742700, 12 bytes long.
H>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>{2002} normal block at 0x027426B8, 12 bytes long.
H>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>М.б. как-то использовать RTTI?
H>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

посмотри здесь

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

. Может поможет.

Здравствуйте, hypnotic, Вы писали:

H>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>Detected memory leaks!

приложение — MFC based?

Здравствуйте, hypnotic, Вы писали:

H>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>Detected memory leaks!
H>Dumping objects ->
H>{2003} normal block at 0x02742700, 12 bytes long.
H>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>{2002} normal block at 0x027426B8, 12 bytes long.
H>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>М.б. как-то использовать RTTI?
H>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

Добавь следующий макрос:

#define _CRTDBG_MAP_ALLOC

Здравствуйте, Odi$$ey, Вы писали:

OE>Здравствуйте, hypnotic, Вы писали:

H>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>Detected memory leaks!

OE>приложение — MFC based?

Да. Но не все классы наследуют от CObject

Здравствуйте, Denwer, Вы писали:

D>Здравствуйте, hypnotic, Вы писали:

H>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>Detected memory leaks!
H>>Dumping objects ->
H>>{2003} normal block at 0x02742700, 12 bytes long.
H>>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>>{2002} normal block at 0x027426B8, 12 bytes long.
H>>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>>М.б. как-то использовать RTTI?
H>>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

D>Добавь следующий макрос:
D>

D>#define _CRTDBG_MAP_ALLOC 
D>

Не помогает. Может потому, что не все классы наследуют от CObject?

Здравствуйте, IvEv, Вы писали:

IE>Здравствуйте, hypnotic, Вы писали:

H>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>Detected memory leaks!
H>>Dumping objects ->
H>>{2003} normal block at 0x02742700, 12 bytes long.
H>>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>>{2002} normal block at 0x027426B8, 12 bytes long.
H>>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>>М.б. как-то использовать RTTI?
H>>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

IE>посмотри здесь

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

. Может поможет.

Не помогает. У меня часть классов не наследуют от CObject и используют stl. Может из-за этого?

Здравствуйте, hypnotic, Вы писали:

H>Здравствуйте, IvEv, Вы писали:

IE>>Здравствуйте, hypnotic, Вы писали:

H>>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>>Detected memory leaks!
H>>>Dumping objects ->
H>>>{2003} normal block at 0x02742700, 12 bytes long.
H>>>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>>>{2002} normal block at 0x027426B8, 12 bytes long.
H>>>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>>>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
Да. Только не при завершении, а при распределении памюти для объектов. Потом по стеку посмотрите, что за объекты

H>>>М.б. как-то использовать RTTI?
Не поможет

H>>>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?
Студии — нет. MFC — да.

IE>>посмотри здесь

Автор(ы): Эдвард Райт

Статья посвящена проблеме, которая постоянно преследует программистов на C/C++, — обнаружению и локализации утечек памяти. Автор демонстрирует применение средств библиотеки времени выполнения (CTR), поставляемой с Visual C++, с помощью которых утечки памяти можно устранить гораздо быстрее и проще, чем методом "пристального взгляда".

. Может поможет.

H>Не помогает.


H>У меня часть классов не наследуют от CObject и используют stl. Может из-за этого?
Наследование тут ни при чем.

Что у вас не получается? Что из почерпнутого из статьи вы пытались применить?

Здравствуйте, hypnotic, Вы писали:

H>Здравствуйте, Denwer, Вы писали:

D>>Здравствуйте, hypnotic, Вы писали:

H>>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>>Detected memory leaks!
H>>>Dumping objects ->
H>>>{2003} normal block at 0x02742700, 12 bytes long.
H>>>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>>>{2002} normal block at 0x027426B8, 12 bytes long.
H>>>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>>>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>>>М.б. как-то использовать RTTI?
H>>>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

D>>Добавь следующий макрос:
D>>

D>>#define _CRTDBG_MAP_ALLOC 
D>>

H>Не помогает. Может потому, что не все классы наследуют от CObject?

Что вы гадаете — "может-не может". Разбираться надо

Здравствуйте, hypnotic, Вы писали:

OE>>приложение — MFC based?
H>Да. Но не все классы наследуют от CObject

CObject здесь ни причем. Если проект — MFC Based, достаточно иметь в начале каждого cpp приведенный Croc-ом блок

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

и тогда в debug-mode для каждого куска памяти выделенного по new в одном из этих cpp и не освобожденного по завершении программы будет указываться имя файла и строка где произошло выделение.

Здравствуйте, Odi$$ey, Вы писали:

skip

К сожалению, данный прием очень плохо работает с stl и boost — утечки памяти выдаются, но именно в том виде, который был дан в вопросе. Поэтому с ними очень трудно бороться. Как раз на днях один мой товарищ с этим долго боролся — он вставлял boost::shared_ptr в CAtlMap и долго мучался с поиском конкретного места, в котором утекает память.

Здравствуйте, hypnotic, Вы писали:

skip

Из моего опыта: если ты используешь MFC и stl — может быть такая ерунда.
Если номера блоков (то, что в фигурных скобках) не меняются — тогда можно попытаться использовать функцию _CrtSetBreakAlloc и с ее помощью найти утечку.
Если же номера блоков меняются от запуска к запуску, очень вероятно, что проблемы в стыке контейнеров MFC и объектов stl / boost. Например, вот такая штука CAtlMap<boost::shared_ptr<CMyObject> > выдает утечки. В этом случае лучше всего отказаться от MFC/ATL контейнеров и использовать контейнеры стандартной библиотеки.

Наверняка, есть и другие причины, по которым может выдаваться не полная информация об утечках, но я с ними не сталкивался (или просто уже не помню )

Здравствуйте, hypnotic, Вы писали:

H>Здравствуйте, Denwer, Вы писали:

D>>Здравствуйте, hypnotic, Вы писали:

H>>>При завершении работы приложения в режиме Debug в VC++7, если есть утечки памяти, выдается сообщение типа:
H>>>Detected memory leaks!
H>>>Dumping objects ->
H>>>{2003} normal block at 0x02742700, 12 bytes long.
H>>>Data: < &t &t > B8 26 74 02 B8 26 74 02 E0 AF D0 01
H>>>{2002} normal block at 0x027426B8, 12 bytes long.
H>>>Data: < 't 't > 00 27 74 02 00 27 74 02 CD CD CD CD
H>>>Возможно ли при завершении приложения отследить объекты каких классов расположены по адресам, по которым есть утечка памяти?
H>>>М.б. как-то использовать RTTI?
H>>>М.б. какие-то дополнительные настройки в студии для остановки перед Dumping objects?

D>>Добавь следующий макрос:
D>>

D>>#define _CRTDBG_MAP_ALLOC 
D>>

H>Не помогает. Может потому, что не все классы наследуют от CObject?

Тут CObject не причем, при включении данного макроса, вместо того что у тебя вывелось на консоль ты увидешь плюс к тому и имена файлов и строки где было выделение памяти, ну а дальше дело техники.

ЗЫ: А ты куда вставлял эту строчку то? Надо в StdAfx.h почти в самое начало, т.е. до всех инклуд.

Здравствуйте, Андрей, Вы писали:

А>Здравствуйте, hypnotic, Вы писали:

А>skip

А>Из моего опыта: если ты используешь MFC и stl — может быть такая ерунда.
А>Если номера блоков (то, что в фигурных скобках) не меняются — тогда можно попытаться использовать функцию _CrtSetBreakAlloc и с ее помощью найти утечку.
А>Если же номера блоков меняются от запуска к запуску, очень вероятно, что проблемы в стыке контейнеров MFC и объектов stl / boost. Например, вот такая штука CAtlMap<boost::shared_ptr<CMyObject> > выдает утечки. В этом случае лучше всего отказаться от MFC/ATL контейнеров и использовать контейнеры стандартной библиотеки.

А>Наверняка, есть и другие причины, по которым может выдаваться не полная информация об утечках, но я с ними не сталкивался (или просто уже не помню )

Да, у меня именно такая ситуация и получилась. В MFC проекте применил библиотеку, использующую stl.
Именно там и была утечка (пришлось расковырять до сонования) для которой не работают предложенные
в ответах механизмы ее обнаружения. Для утечек объектов классов, не хранящихся в контейнерах stl прекрасно
работает #define _CRTDBG_MAP_ALLOC.
Всем спасибо!