Задача ослеживания утечек памяти.

Откройте отладчик WinDbg и загрузите любое приложение и попробуйте найти такое значение 0xDEADBEEF. И тогда я съем свой галстук.

Был не прав, действительно есть такие значения. Во блин, надо же.
Вот такое в калькуляторе уже не нашел
s 0 L?0xffffffff 0xde 0xad 0xbe 0xef 0xde 0xad

Правда, это уже 6 байт.

Сейчас попробую просканировать всю системную память, включая ядро.

 

neutronion
вероятность появления любого значения от 0 до 2^N не нулевая. вас порадует, если ваш метод будет ошибаться всего в 1 случае из 4х?
если уж речь о совершенном коде, то он должен быть более надежным и универсальным.

 

Момент, вы загрубили слегка в вычислениях, речь идет не об одном байте, а
о наборе байт, следовательно чем больше байт используем, тем вероятность идентичности памяти приближается к нулю. Кроме того можно сканить память
на предмет магических значений до выделения памяти. Думаю с практической точки зрения, вполне может быть приемлемо, как простой брутфорсный способ.
Кстати говоря - это интересная комбинаторная задачка, можно посчитать вероятность появления любого набора из последовательности n байт в M памяти.

 

neutronion

прога выделяет 3 сотни блочков под 1-2-3 дворда. каждый помечается 12-байтной сигнатурой. не слишком ли расточительно?
кроме того, вероятность случайного возникновения похожей комбинации просто уменьшается, но не исключается.

память сперва выделяется, потом заполняется. что вам даст предварительное сканирование?

 

Предварительное сканирование дает понять, есть ли в памяти уже такие магические числа. Кто выделяет память по 1-2-3 дворда? Выделение памяти, происходит страницами по 4 кг, если верить Рихтеру, хотя это конечно не имеет значения. Кроме того это можно делать в дебажном варианте.

 

если кодируете на C++ то RAII и смартпоинтеры избавят вас от этой головной боли))

 

в том то и проблема, нужно на чистом С. Причем так, чтобы можно было использовать в дровах. Поэтому отлаживаю пока в юзерлэнде. Так как любая ошибка в кернелэнде, знаете чего бывает

 

кажется посчитал правильно, поправьте, если не прав.
Вероятность появления 4 байт определенного значения в памяти развна:
Всю физическую память нужно разделить на 255 в четвертой степени, если доступна память 4 гига, то это примерно один к одному, если же расчитать последовательность на 6 байт, то получаем значение уже 1 к 16000, что такая
память будет пристутствовать в 4 гигах. Ну а если учесть, что память отдельного процесса ограничена 2 гигабайтами получим уже 1 к примерно 32 000, а если еще и учесть, что реально среднее приложение использует на порядок меньше памяти скажем 200 метров, но верояность появления такой последовательности падает 1 к 320 000 , плюс если ввести в магическое чило байт, которые не имеет ассеблерного эквивалента, то вся память кода, тоже уходит лесом , это намного меньше даже, чем вероятность падения астероида Апофиз, который уничтожит землю. Вообщем практически вполне приемлемо.

 

neutronion

class A {
AnyType* var; // буфер, структура, класс. что угодно

// куча методов
};

foo(){
A a;
// чтото там
}

пример малоченья sizeof(void*) (4 или 8 байт. в зависимости от разрядности)

это не то выделение. тут вы говорите о выделении страницами. а утечку вы искать будете при выделении в хипе.
страницы посмотреть как раз несложно. есть спец функции.

 

neutronion

те, если так рассуждать, то вероятность встретить в памяти

00 00 00 00

или

cc cc cc cc

настолько мала?

 

сс не катит это ассеблерная команда int 3. Как я и говорил такой байт идет лесом. Кроме того твои слова, льют только на мою мельницу, поскольку само собой, есть такие разновидности наборов байт, которые точно и очень часто встречаются, такие как сссссс и 00000, следовательно, если избегать еще и таких наборов, то вероятность встретить магическое число вообще будет практически равна нулю.

 

neutronion

осталось только заменить слова "магическое число" числом, а потом доказать, что такое число гарантировано никогда не всретится в вашем дрове. тем более, что в дрове

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

вы еще таких ошибок не копали? ото коррида (особенно, если там С++ с его кучей теневых аллокеров)

 

вероятность есть, но она ничтожна, кроме того это нужно только для тестирования кода, а не для промышленного релиза. Если на этапе тестирования встречаем, разбираемся. Если встретили, то вероятность
крайне низка, попробуйте найти код в любом приложении, без чита конечно,
например c0 de de ad

 

c0dedead или deadc0de - распространенная в учебниках метка ссылок. я б не положился, что никогда ее не встречу. не один я туторы читал.

но если вам настолько охота это использовать - чего вы спрашиваете? сбойнет - не мне ж отлаживать.

 

но лучше тогда использовать простое число. меньше вероятность что оно получится в результате какогото рассчета.

 

если еще не искать в памяти стека, и в секциях данных и ресурсов... Экзешника и всех библиотек, то кол-во памяти которое надо просканить уменьшается. Т.е. сканить только автоматический хип и динамический. Надо проконсультироваться с Рихтером.

Рихтер к сожалению не глубоко копнул, прикладываю документ о структуре хипа, кому-нибудь может пригодиться.

 

neutronion

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

вообще, это интересно. если будете проводить рос что там и как, отписывайтесь. будет интересно почитать.

 

Вы меня улыбаете!! Все это можно получить из имиджа как правило. По каким адресам, что мапится, стек, код, данные все это легко получить, самые простые вирусы это делают не напрягаясь. Как по вашему Ида все достает? Или те же дебаггеры? Подход конечно необычный, я бы сказал хацкерский, зато позволяет взглянуть на суть, без всякого высокоуровневого нонсенса, который нам навязали ребята из Мита. Правда сделали они это не со зла.

 

neutronion

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

вы б таки меньше улыбались. копируя "простой вирус" вы не напрягаясь получите такую же простую и глючную поделку умеющую почти ничего и работающую на одной вашей машине и только в той проге к которой вы это притирали.

---
но еще раз говорю - это дело ваше. лемминги, бывает, целыми стадами топятся в море. для нас дикость - для них образ жизни и старинная культурная традиция.

 

1) Кто сказал, что нужно работать со страницами, вы еще скажите с физ. адресами. Нет работать надо только с виртуальными адресами.
2) Информацию любого стека любого треда получаем из tib.
FS:[0x04] 4 Win9x and NT Top of stack
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

За что Рихтер мне не очень нравиться, это то, что он умалчивает о такого рода инфоромации, хотя это было бы очень полезно.