H>Если есть PDB-шки, то используйте Windows Debugging Tools, в частности UDMH — сделайте дамп в начале работы и когда память отъестся. Потом ей же проанализируйте и получите расчепятку в какой строке и сколько выделяется памяти.

ссылка о том, как это делается http://support.microsoft.com/kb/268343

21.07.2010 18:17, Аноним 338 пишет:
>
> Игровое приложение.
> Во время игры ест больше и больше памяти.
> Ориентировочно +30-40Mb за час игры.
> Утечек памяти нет (точнее, были исправлены все, выявленные с помощью
> VisualLeakDetector).
О, если были утечки, которые выявлены были с помощью VLD, то я вам
сочувствую.
Скажите какая игра, чтобы не качнуть сдуру.

>
> Как узнать куда расходуется память во время работы программы?
> Может посоветуете какие-то средства или приемы для этого?
Голова и прямые руки.

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

А>Игровое приложение.
А>Во время игры ест больше и больше памяти.
А>Ориентировочно +30-40Mb за час игры.

А>Как узнать куда расходуется память во время работы программы?
А>Может посоветуете какие-то средства или приемы для этого?

Вот тут Raymond Chen описывает один до гениальности простой метод определения утечек.

Раз у нас что-то течёт, значит, через некоторое время его будет много. Тыкаем в произвольное место в памяти — и с большой вероятностью это будет утёкший объект. Если мы можем по шестнадцатеричному дампу куска памяти определить, что это за объект — мы нашли утечку.

Проблема:

Игровое приложение.
Во время игры ест больше и больше памяти.
Ориентировочно +30-40Mb за час игры.
Утечек памяти нет (точнее, были исправлены все, выявленные с помощью VisualLeakDetector).

Как узнать куда расходуется память во время работы программы?
Может посоветуете какие-то средства или приемы для этого?
Спасибо.

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

А>Как узнать куда расходуется память во время работы программы?

Ответ может быть крайне неожиданным. Например, когда я последний раз разбирался с памятью в своей программе, выяснилось, что память съедается фрагментацией. Пришлось сделать простенький SLAB allocator, и проблему как рукой сняло.

У вас часом нет огромного количества мелких аллокаций?

Чем такое автоматизированно ловить, я не знаю. Я лично мозгами ловил

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

V>О, если были утечки, которые выявлены были с помощью VLD, то я вам
V>сочувствую.
Спасибо за подсказку, что VLD плохо справляется со своей задачей.
Воспользовался студийным _CRTDBG_MAP_ALLOC + _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF)
Нашло лики, порядка 10кб за час игры. То есть проблема есть, но она не соизмерима с описанной мною ранее (30мб)
Не подскажете, находит ли такой способ все лики? Или может еще какой совет?
Спасибо.

V>Скажите какая игра, чтобы не качнуть сдуру.
Вы в такие не играете.

V>Голова и прямые руки.
Ну вот, Вы же не знаете откуда этот код, в каких условиях создавался, какие сроки и т.д.
Сейчас в проекте 3.5мб с++ кода в порядка 600 исходных файлах + 3.5мб скриптов.
Вроде и не много, но у меня не настолько прямые руки, чтоб сходу увидеть в чем проблема.

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

А>Проблема:

А>Игровое приложение.
А>Во время игры ест больше и больше памяти.
А>Ориентировочно +30-40Mb за час игры.
А>Утечек памяти нет (точнее, были исправлены все, выявленные с помощью VisualLeakDetector).

А>Как узнать куда расходуется память во время работы программы?
А>Может посоветуете какие-то средства или приемы для этого?
А>Спасибо.

Если есть PDB-шки, то используйте Windows Debugging Tools, в частности UDMH — сделайте дамп в начале работы и когда память отъестся. Потом ей же проанализируйте и получите расчепятку в какой строке и сколько выделяется памяти.

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

V>21.07.2010 18:17, Аноним 338 пишет:
>>
>> Игровое приложение.
>> Во время игры ест больше и больше памяти.
>> Ориентировочно +30-40Mb за час игры.
>> Утечек памяти нет (точнее, были исправлены все, выявленные с помощью
>> VisualLeakDetector).
V>О, если были утечки, которые выявлены были с помощью VLD, то я вам
V>сочувствую.
V>Скажите какая игра, чтобы не качнуть сдуру.

>>
>> Как узнать куда расходуется память во время работы программы?
>> Может посоветуете какие-то средства или приемы для этого?
V>Голова и прямые руки.

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

H>>Если есть PDB-шки, то используйте Windows Debugging Tools, в частности UDMH — сделайте дамп в начале работы и когда память отъестся. Потом ей же проанализируйте и получите расчепятку в какой строке и сколько выделяется памяти.

H>ссылка о том, как это делается http://support.microsoft.com/kb/268343

Большое спасибо. Буду пробовать.
И еще, не подскажете, как с поиском утечек памяти справляется студийный _CRTDBG_MAP_ALLOC?

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

Pzz>Ответ может быть крайне неожиданным. Например, когда я последний раз разбирался с памятью в своей программе, выяснилось, что память съедается фрагментацией. Пришлось сделать простенький SLAB allocator, и проблему как рукой сняло.
Pzz>У вас часом нет огромного количества мелких аллокаций?
Pzz>Чем такое автоматизированно ловить, я не знаю. Я лично мозгами ловил

Спасибо. А как Вы выяснили, что память съедается фрагментацией?
Мелких аллокаций хватает, правда сомневаюсь что их настолько много, чтобы расходовать 30мб в час.
Хотя, все может быть ...

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

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

H>>>Если есть PDB-шки, то используйте Windows Debugging Tools, в частности UDMH — сделайте дамп в начале работы и когда память отъестся. Потом ей же проанализируйте и получите расчепятку в какой строке и сколько выделяется памяти.

H>>ссылка о том, как это делается http://support.microsoft.com/kb/268343

sqb>Большое спасибо. Буду пробовать.
sqb>И еще, не подскажете, как с поиском утечек памяти справляется студийный _CRTDBG_MAP_ALLOC?

Если Вы уверены, что вся память выделеятся только через CRT, то хорошо. Вот только в реальной жизни так не бывает. Так что UDMH Ваш лучший друг.

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

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

Pzz>>Ответ может быть крайне неожиданным. Например, когда я последний раз разбирался с памятью в своей программе, выяснилось, что память съедается фрагментацией. Пришлось сделать простенький SLAB allocator, и проблему как рукой сняло.
Pzz>>У вас часом нет огромного количества мелких аллокаций?

sqb>Спасибо. А как Вы выяснили, что память съедается фрагментацией?
sqb>Мелких аллокаций хватает, правда сомневаюсь что их настолько много, чтобы расходовать 30мб в час.
sqb>Хотя, все может быть ...

Может вы попробуете включить Low Fragmentation Heap и посмотрите есть изменения или нет?
http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx

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

А>Проблема:

А>Игровое приложение.
А>Во время игры ест больше и больше памяти.
А>Ориентировочно +30-40Mb за час игры.
А>Утечек памяти нет (точнее, были исправлены все, выявленные с помощью VisualLeakDetector).

А>Как узнать куда расходуется память во время работы программы?
А>Может посоветуете какие-то средства или приемы для этого?
А>Спасибо.

1 раз словил утечки при логировании, AnsiString от борланда не дружил с тернартым оператором (либо сам борлад):

Т.е. (для примера)
String a = true ? String("bla bla") : String("alb alb");
вызывало лик.

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

>> Игровое приложение.
>> Во время игры ест больше и больше памяти.
>> Ориентировочно +30-40Mb за час игры.
>> Утечек памяти нет (точнее, были исправлены все, выявленные с помощью
>> VisualLeakDetector).
V>О, если были утечки, которые выявлены были с помощью VLD, то я вам
V>сочувствую.
V>Скажите какая игра, чтобы не качнуть сдуру.

>>
>> Как узнать куда расходуется память во время работы программы?
>> Может посоветуете какие-то средства или приемы для этого?
V>Голова и прямые руки.

А что не так с VLD? Давно ей пользуюсь, и всегда показания совпадают с CRT.