Здравствуйте, Tom, Вы писали:
Tom>Ээээ а разве возможно порчей стека добиться того, что "Vectored Exceptions Handler" будет не вызываться? Мне кажется он к стеку совсем не относится...
Ну представь, вызвался твой handler, а на выходе из него команда ret переносит исполнение кода не обратно в систему и на вызов следующего handler-а, а куда-то в [censored]. И другие handler-ы могут не вызываться...
Ну вот пример. На коленке и работает только под отладкой, но м.б. будет понятно, что я хочу сказать...
Если модификацию стека в VectoredHandler2 не делать, то вызываются оба хандлера.
Если испортить стек в VectoredHandler2, то можно сделать так, чтобы VectoredHandler1 не вызовется.
long WINAPI VectoredHandler1(PEXCEPTION_POINTERS pstEI)
{
// не вызывается...return EXCEPTION_CONTINUE_SEARCH;
}
long WINAPI VectoredHandler2(PEXCEPTION_POINTERS pstEI)
{
// Пример для отладки - типа меняем адрес возврата на мусор.
// В моем случае точка 0x00416B75 - вызов первой RemoveVectoredExceptionHandler в main.
DWORD dw;
__asm mov dw, ebp;
dw += sizeof(DWORD);
*(DWORD*)(void*)dw = 0x00416B75;
return EXCEPTION_CONTINUE_SEARCH;
}
int _tmain(int argc, _TCHAR* argv[])
{
void* p1 = AddVectoredExceptionHandler(1, VectoredHandler1);
void* p2 = AddVectoredExceptionHandler(2, VectoredHandler2);
__try
{
int x = 1;
int y = 0;
int z = x / y;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
}
RemoveVectoredExceptionHandler(p1);
RemoveVectoredExceptionHandler(p2);
return 0;
}
Здравствуйте, Tom, Вы писали:
Tom>Опишу ситуацию, есть некоторое распределённое/клиент серверное приложение, и живёт в нём хитрый и злой мега баг. Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями (любя мы называем его засранцем ). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
если известна область памяти которая затирается — если повезет и она одна и та же иногда, то есть решение
— подключите к машине отладчик удаленный (WinDbg + VM Ware сгодится)
— путем проигрывания проблемного сценария в виртуалке (чтобы шансы на воспроизведение были выше, лучше заснапшотить поближе к моменту падения и одно и тоже состояние проигрывать в надежде на те же адреса и т.п.), можно сделать так:
— сначала падаем и смотрим по какому адресу проблема, адрес-диапазон запоминаем
— перезапуск виртуалки и в отладчике ставим бряки на запись по этому адресу
— удим рыбу
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Уж незнаю в какой этот форум, модераторы если что поправят.
Опишу ситуацию, есть некоторое распределённое/клиент серверное приложение, и живёт в нём хитрый и злой мега баг. Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями (любя мы называем его засранцем ). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
Здравствуйте, Tom, Вы писали:
Tom>Опишу ситуацию, есть некоторое распределённое/клиент серверное приложение, и живёт в нём хитрый и злой мега баг. Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями (любя мы называем его засранцем ). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
PE>А всегда затирает одинаковые участки памяти ?
Нет, но есть одно проявление давольно стабильное, какает в память COM-а, таким макаром, что последующий вызов CoCreateInstance валится на AV при чтении своих внутренних кэшей
Здравствуйте, Tom, Вы писали:
PE>>А всегда затирает одинаковые участки памяти ? Tom>Нет, но есть одно проявление давольно стабильное, какает в память COM-а, таким макаром, что последующий вызов CoCreateInstance валится на AV при чтении своих внутренних кэшей
А если защитить какую то область памяти от модификации и ловить исключение ?
PE>А если защитить какую то область памяти от модификации и ловить исключение ?
Уже пробовали, на старте выделяем 500m защищённой от доступа памяти, так он туда не попадает, или попадает но мы его не видим.
Я уже начинаю думать, что какают совсем не в user mode, вот к примеру могут какать при асинхронном вводе выводе, а там запись в память, как я понимаю выполняет сам драйвер
Здравствуйте, Tom, Вы писали:
PE>>А если защитить какую то область памяти от модификации и ловить исключение ? Tom>Уже пробовали, на старте выделяем 500m защищённой от доступа памяти, так он туда не попадает, или попадает но мы его не видим. Tom>Я уже начинаю думать, что какают совсем не в user mode, вот к примеру могут какать при асинхронном вводе выводе, а там запись в память, как я понимаю выполняет сам драйвер/
А если несколько фрагментов разное время ? Выделить нужно несколько регионов адресного пространства, без выделенной памяти, тут точно должно свалиться хучь в юзер, хучь в кернел
Здравствуйте, Tom, Вы писали:
PE>>А всегда затирает одинаковые участки памяти ? Tom>Нет, но есть одно проявление давольно стабильное, какает в память COM-а, таким макаром, что последующий вызов CoCreateInstance валится на AV при чтении своих внутренних кэшей
А если напихать побольше логов? Потом смотреть, чего между удачным и не удачным CoCreateInstance произошло и пытаться детализировать потихоньку?
PE>А если несколько фрагментов разное время ? Выделить нужно несколько регионов адресного пространства, без выделенной памяти, тут точно должно свалиться хучь в юзер,
Не помогает
PE>хучь в кернел
Вот представь начинаешь ты асинхронную операцию чтения скажем из сокета, передаёшь буфер, функция recv возвращается мгновенно, и вот сразу после этого память освобождается. А потом выделяется другим кодом, и скажем меньше чем мыло передано в recv, таким образом, я предпологаю, часть памяти будет затёрта, при достижении конца блока запись явно прекратиться, но кому кидать эксепшин? Операция то асинхронная... Вот я предпологаю нечто такое, но всё равно непонятно как енто отловить
Если уже после креша точно известен адрес памяти по которому были записаны нули, то я бы начал с с перехвата всех функций выделения и освобождения памяти, как библиотечных, так и апишных с целью выяснения конкретной функции выделившей память. Я бы писал данные о перехвате в сокет через отдельную сетевую карту. Желательно в БД, чтобы потом было легче анализировать.
Здравствуйте, adontz, Вы писали:
A>Если уже после креша точно известен адрес памяти по которому были записаны нули, то я бы начал с с перехвата всех функций выделения и освобождения памяти, как библиотечных, так и апишных с целью выяснения конкретной функции выделившей память. Я бы писал данные о перехвате в сокет через отдельную сетевую карту. Желательно в БД, чтобы потом было легче анализировать.
А толку ? ЗАпись происходит по неинициализированному указаителю. При чем здесь выделение ?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>А толку ? Запись происходит по неинициализированному указаителю. При чем здесь выделение?
Не факт. Может быть указатель когда-то был валидным, а потом объект удалили/перенесли, а сообщить забыли. Учитывая что портится именно COM память я бы так и думал.
A>Не факт. Может быть указатель когда-то был валидным, а потом объект удалили/перенесли, а сообщить забыли. Учитывая что портится именно COM память я бы так и думал.
Замечали порчу памяти не только COM-а, были случайные попадания и в другие места, просто COM-у больше всех везёт, там беда проявляется с большей стабильностью
Здравствуйте, Tom, Вы писали:
M>>Методом исключения функционала не получиться? Tom>Получиться, правда это долгая песня, но буду пробовать.
А пишуться строго нолики или еще какая цыфирь?
Попробуй отловить вызовы к IsBadReadPtr/IsBadWritePtr.
Или если пользуешь MFC, то "обнулить" AssertValid всех классов.
Вообщем покапать в этой области...
PS: У меня было такое что на ASSERT_POINTER вылетал D3D8Surface, а это уже как бы КОМ
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
А много ноликов? Может проще найти места где пишется много ноликов? Все ZeroMemory для начала? А если известно сколько ноликов (и всегда одинаковое количество), то и это может помочь.
A>А много ноликов? Может проще найти места где пишется много ноликов? Все ZeroMemory для начала?
Нереально, обьём кода огромный, да и написан при помощи spagetti style
По количество ноликов — интересная идея, буду теперь их считать
Здравствуйте, Tom, Вы писали:
A>>А много ноликов? Может проще найти места где пишется много ноликов? Все ZeroMemory для начала? Tom>Нереально, обьём кода огромный, да и написан при помощи spagetti style
Нет, просто пусть ZeroMemory не только обнуляет память но и журналирует адрес/размер облулённого участка. Учитывая что это макрос, "перехватить" его можно простым #define.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Tom, Вы писали:
A>>>А много ноликов? Может проще найти места где пишется много ноликов? Все ZeroMemory для начала? Tom>>Нереально, обьём кода огромный, да и написан при помощи spagetti style
A>Нет, просто пусть ZeroMemory не только обнуляет память но и журналирует адрес/размер облулённого участка. Учитывая что это макрос, "перехватить" его можно простым #define.
Простого дефайна скорее всего не хватит, потому как эта функция(на самом деле это макрос) может вызыватся откуда угодно.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Простого дефайна скорее всего не хватит, потому как эта функция(на самом деле это макрос) может вызыватся откуда угодно.
Ну, во-первых, можно ключик /D компилятора использовать, а, во-вторых, ради такого и windows.h подправить не жалко.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>Простого дефайна скорее всего не хватит, потому как эта функция(на самом деле это макрос) может вызыватся откуда угодно.
A>Ну, во-первых, можно ключик /D компилятора использовать, а, во-вторых, ради такого и windows.h подправить не жалко.
Здравствуйте, Tom, Вы писали:
Tom>Уж незнаю в какой этот форум, модераторы если что поправят.
Tom>Опишу ситуацию, есть некоторое распределённое/клиент серверное приложение, и живёт в нём хитрый и злой мега баг. Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями (любя мы называем его засранцем ). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
А можно подробности. А то я тут две недели ловил схожэий баг (правдо, "везло" не КОМу).
Дело было в связке. многопоточность + stl от 6-й стидии (дело было под виндой).
Если окружение схожее — свисти, расскажу.
Возможно, некая ошибка вызывает порчу стека и точек возврата из функций соответственно. После чего, код начинает "гулять" по произвольным местам... Поэтому, не можете заловить, кто это делает (может не раскручиваться стек функций или не вызываться какие-то catch-блоки).
Например, из-за того, что где-то аргументы для форматирования строк неправильные?
Здравствуйте, rus blood, Вы писали:
RB>Здравствуйте, Tom, Вы писали:
RB>Возможно, некая ошибка вызывает порчу стека и точек возврата из функций соответственно. После чего, код начинает "гулять" по произвольным местам... Поэтому, не можете заловить, кто это делает (может не раскручиваться стек функций или не вызываться какие-то catch-блоки).
Ого, гуляющий код, это круто! Я вообще склоняюсь к мысли, что надо всё переписать под .Net
P.S. Кажется я опять отнял чей-то хлеб
Здравствуйте, adontz, Вы писали:
A>Ого, гуляющий код, это круто! Я вообще склоняюсь к мысли, что надо всё переписать под .Net A>P.S. Кажется я опять отнял чей-то хлеб
Поверь, буквально недавно такое наблюдал.
Можешь сам попробовать. Пример сделать несложно.
RB>>Поверь, буквально недавно такое наблюдал. RB>>Можешь сам попробовать. Пример сделать несложно.
Tom>Ээээ а разве возможно порчей стека добиться того, что "Vectored Exceptions Handler" будет не вызываться? Мне кажется он к стеку совсем не относится...
Порчей стека можно добиться теоретически чего угодно. Например, есть шанс, что стек попортится, сформировав валидный с\с++ компилятор + код драйвера, все это дело откомпилится, установится и будет писать нолики куда захочет. Вероятность подобного события оставляю посчитать вам
А вообще, конечно, если серьезно, самый лучший вариант в таких случаях — дихотомия. Как говорится, гильотина — лучее средство от головной боли. Располовинивать, пока не выявится хотя бы модуль, ответственный за баг. Впрочем, и этот метод часто не приносит никаких результатов. Сам недавно общался с таким проектом
Здравствуйте, Tom, Вы писали:
Tom>Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями
Мне в свое время подобные глюки удалось свести практически к нулю таким вот комплексом мер:
Собственный менеджер динамической памяти (я делал переопределением new/delete, но может оказаться проще сделать библиотеку со своими xxxAlloc/xxxFree и подсунуть при линковке). Менеджер создает классические обрамляющие поля вокруг каждого блока, расписывая их известными константами, а сами блоки забивает мусором с установленным старшим битом, чтобы проще ловились неинциализированные указатели.[/*]
В начало конструктора каждого класса, если объекты создаются не динамически, вставляется забивание всего объекта таким же мусором.[/*]
В каждом классе имеется функция Check, вызываемая из каждого мало-мальски важного метода, и проверяющая целостность объекта.[/*]
По коду раскиданы Assert'ы, регулярно проверяющие как условия выполнения, так и целостность кучи, основных списков, ключевых объектов и т.п.[/*]
Таким образом практически сразу ловятся всяческие недоинициализации и порчи, без контроля приводящие к отдаленным эффектам типа Вашего. Собственно, многое из этого есть в перечисленных сторонних тулзах, но мне было удобнее реализовать гибкий встроенный контроль, введя переменную для глубины контроля, чтобы понапрасну не тормозило.
Еще имеет смысл проверить функции на побочные эффекты. Я как-то около месяца не мог найти, отчего портились некоторые поля в двухпроцессорной конфигурации, но только в отладочной сборке — релиз работал безупречно. В итоге выяснилось, что IsBadWritePtr, который я на автомате пользовал еще с 16-разрядного кода, проверяет тупой перезаписью, и при отсутствии синхронизации может испортить данные, которые меняет параллельный поток.
Хотя заниматься всем перечисленным в спагетти-коде — врагу не пожелаю
Здравствуйте, Andrew S, Вы писали:
AS>Порчей стека можно добиться теоретически чего угодно. Например, есть шанс, что стек попортится, сформировав валидный с\с++ компилятор + код драйвера, все это дело откомпилится, установится и будет писать нолики куда захочет. Вероятность подобного события оставляю посчитать вам
Ну я не про причину появления ноликов, а про то, что поймать не удается...
Да и вообще, м.б. где-то есть ошибка, не связананная с ноликами, а появление ноликов — результат перехвата этой ошибки.
ЕМ>Собственный менеджер динамической памяти (я делал переопределением new/delete, но может оказаться проще сделать библиотеку со своими xxxAlloc/xxxFree и подсунуть при линковке). Менеджер создает классические обрамляющие поля вокруг каждого блока, расписывая их известными константами, а сами блоки забивает мусором с установленным старшим битом, чтобы проще ловились неинциализированные указатели.[/*] ЕМ>В начало конструктора каждого класса, если объекты создаются не динамически, вставляется забивание всего объекта таким же мусором.[/*] ЕМ>В каждом классе имеется функция Check, вызываемая из каждого мало-мальски важного метода, и проверяющая целостность объекта.[/*] ЕМ>По коду раскиданы Assert'ы, регулярно проверяющие как условия выполнения, так и целостность кучи, основных списков, ключевых объектов и т.п.[/*] ЕМ>
ага и добавлю, что все это в настоящее время делает Driver Verifier & Application Verifier
так что городить все вышеприведенное имеет смысл на ОС раньше 2000, где еще такого счастья не было
да и App Verifier автору топика не помог, он сразу это написал
PS отмечу что подобные "свои" или стянутые у Руссиновича verifiers (MemAllocatePool and other MemXxx wrappers кто помнит) были практически у всех разработчиков в то время...
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Ага, щаз Их не иначе, как телепаты писали, и научили догадываться, как проверять целостность каждого объекта И статически размещенные объекты они тоже мусором прописывают, чтобы правильность инициализации в конструкторе проверить?
VAB>PS отмечу что подобные "свои" или стянутые у Руссиновича verifiers (MemAllocatePool and other MemXxx wrappers кто помнит) были практически у всех разработчиков в то время...
Только блоки памяти проверять — это меньшая часть заботы...
Может поможет
Помню такую эпопею
Немодальный диалог созданый через new -> PostNcDestroy-> в нем delete this;
И в каком-то обработчике (сейчас хоть убей не помню толи WM_TIMER) без проверки на
::IsWindow(m_hWnd) модифицировалось int поле класса диалога уже после delete this;
Причем этот адрес был уже другим блоком (хотя не всегда)
Тоесть как ты говорищ какало в другие блоки
[Skip]
VAB>если известна область памяти которая затирается — если повезет и она одна и та же иногда, то есть решение
VAB>- подключите к машине отладчик удаленный (WinDbg + VM Ware сгодится) VAB>- путем проигрывания проблемного сценария в виртуалке (чтобы шансы на воспроизведение были выше, лучше заснапшотить поближе к моменту падения и одно и тоже состояние проигрывать в надежде на те же адреса и т.п.), можно сделать так: VAB>- сначала падаем и смотрим по какому адресу проблема, адрес-диапазон запоминаем VAB>- перезапуск виртуалки и в отладчике ставим бряки на запись по этому адресу VAB>- удим рыбу
Могу предложить даже готовое решение как выловить такое место.
Есть такой продукт SmartHeap, который реализует скоростной менеджер кучи (подменяются все New, Alloc, etc.). В нем есть Debug DLL со множествами способов отладки таких ситуаций:
1. К каждому выделенному указателю присобачивается вначале и в конце дополнительные контрольные байты. Если их кто то перетер то через секунд 5 (настривается) выскакивает диалжг "Типа AAA указатель такой то был перетерт" — типа переполнение буфера, с дикой информацией Время выделения, CallStack выделения, Поток, иеще куча всего.
2. Некоторые указатели можна поставить на мониторинг, система буте следить что бы в них ничего не изменилось, случайно Работает по принципу чеканья области памяти на CRC через определенное время
3. DeferFree — интересная штука. Вы освобождаете указатель, но система не отдает его обратно в кучу, а держит его определенное время, забивает его специальными символами и следит что бы в него никто не записал.
4. Может и не все вспомнил... Читайте что можна тут: HeapAgent. Если заинтересовало, могу для теста выслать (продукт совсем и даже очень не бесплатный)
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Valery A. Boronin, Вы писали:
D>[Skip]
VAB>>если известна область памяти которая затирается — если повезет и она одна и та же иногда, то есть решение
VAB>>- подключите к машине отладчик удаленный (WinDbg + VM Ware сгодится) VAB>>- путем проигрывания проблемного сценария в виртуалке (чтобы шансы на воспроизведение были выше, лучше заснапшотить поближе к моменту падения и одно и тоже состояние проигрывать в надежде на те же адреса и т.п.), можно сделать так: VAB>>- сначала падаем и смотрим по какому адресу проблема, адрес-диапазон запоминаем VAB>>- перезапуск виртуалки и в отладчике ставим бряки на запись по этому адресу VAB>>- удим рыбу
D>Могу предложить даже готовое решение как выловить такое место. D>Есть такой продукт SmartHeap, который реализует скоростной менеджер кучи (подменяются все New, Alloc, etc.). В нем есть Debug DLL со множествами способов отладки таких ситуаций:
D>1. К каждому выделенному указателю присобачивается вначале и в конце дополнительные контрольные байты. Если их кто то перетер то через секунд 5 (настривается) выскакивает диалжг "Типа AAA указатель такой то был перетерт" — типа переполнение буфера, с дикой информацией Время выделения, CallStack выделения, Поток, иеще куча всего.
D>2. Некоторые указатели можна поставить на мониторинг, система буте следить что бы в них ничего не изменилось, случайно Работает по принципу чеканья области памяти на CRC через определенное время
D>3. DeferFree — интересная штука. Вы освобождаете указатель, но система не отдает его обратно в кучу, а держит его определенное время, забивает его специальными символами и следит что бы в него никто не записал.
D>4. Может и не все вспомнил... Читайте что можна тут: HeapAgent. Если заинтересовало, могу для теста выслать (продукт совсем и даже очень не бесплатный)
Если можно — вышли
PS:
А чем вышеописанные действия отличаются от того, что делает DevPartner? Просто с ним воспроизвести данный баг — нереально, из за огромного падения производительности
в ядре и user mode соотв.
ЕМ>Ага, щаз Их не иначе, как телепаты писали, и научили догадываться, как проверять целостность каждого объекта И статически размещенные объекты они тоже мусором прописывают, чтобы правильность инициализации в конструкторе проверить?
выделяемые блоки памяти таким макаром защищаются, это точно. с конструкторами же в С тяжко.
насчет постоянной проверки целостности — это уже конечно руками ибо критерий целостности в общем виде не совсем ясен...
но все равно первые 2 пункта из 4х покрываются
VAB>>PS отмечу что подобные "свои" или стянутые у Руссиновича verifiers (MemAllocatePool and other MemXxx wrappers кто помнит) были практически у всех разработчиков в то время...
ЕМ>Только блоки памяти проверять — это меньшая часть заботы...
...и тем не менее почему бы ее не поручить спец инструментам
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>с конструкторами же в С тяжко.
Понятно, что "конструктором" называется код, инициализирующий структуру данных Как он оформлен — дело десятое. Поэтому в C++ и удобнее такие проверки вводить в конструкторе/деструкторе.
VAB>насчет постоянной проверки целостности — это уже конечно руками ибо критерий целостности в общем виде не совсем ясен...
Тоже гораздо удобнее в C++. Заводится в каждом классе функция Check, и натыкивается вызовов везде, где можно, включая обращения к объектам из "чужих" классов. В plain C придется извращаться с префиксами/суффиксами, теряется прозрачность.
ЕМ>>Только блоки памяти проверять — это меньшая часть заботы...
VAB>...и тем не менее почему бы ее не поручить спец инструментам
Хотя бы потому, что специнструменты сообщат лишь о факте нарушения, и не более того. Например, Driver Verifier, обнаружив при выгрузке драйвера неосвобожденные блоки памяти, не находит ничего умнее, как свалить систему в BSOD, указав только количество неосвобожденных блоков, а толку с этого — почти никакого. Собственная же система управления памятью, во-первых, перечислит все блоки с адресами, размерами и метками (либо адресами, из которых вызывался new), а, во-вторых, сама их освободит. Чаще всего ничем страшным это не грозит, на перезагрузках экономится немало времени.
Already sent
Tom>PS: Tom> А чем вышеописанные действия отличаются от того, что делает DevPartner? Просто с ним воспроизвести данный баг — нереально, из за огромного падения производительности
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Valery A. Boronin, Вы писали:
D>[Skip]
VAB>>если известна область памяти которая затирается — если повезет и она одна и та же иногда, то есть решение
VAB>>- подключите к машине отладчик удаленный (WinDbg + VM Ware сгодится) VAB>>- путем проигрывания проблемного сценария в виртуалке (чтобы шансы на воспроизведение были выше, лучше заснапшотить поближе к моменту падения и одно и тоже состояние проигрывать в надежде на те же адреса и т.п.), можно сделать так: VAB>>- сначала падаем и смотрим по какому адресу проблема, адрес-диапазон запоминаем VAB>>- перезапуск виртуалки и в отладчике ставим бряки на запись по этому адресу VAB>>- удим рыбу
D>Могу предложить даже готовое решение как выловить такое место. D>Есть такой продукт SmartHeap, который реализует скоростной менеджер кучи (подменяются все New, Alloc, etc.). В нем есть Debug DLL со множествами способов отладки таких ситуаций:
D>1. К каждому выделенному указателю присобачивается вначале и в конце дополнительные контрольные байты. Если их кто то перетер то через секунд 5 (настривается) выскакивает диалжг "Типа AAA указатель такой то был перетерт" — типа переполнение буфера, с дикой информацией Время выделения, CallStack выделения, Поток, иеще куча всего.
D>2. Некоторые указатели можна поставить на мониторинг, система буте следить что бы в них ничего не изменилось, случайно Работает по принципу чеканья области памяти на CRC через определенное время
D>3. DeferFree — интересная штука. Вы освобождаете указатель, но система не отдает его обратно в кучу, а держит его определенное время, забивает его специальными символами и следит что бы в него никто не записал.
D>4. Может и не все вспомнил... Читайте что можна тут: HeapAgent. Если заинтересовало, могу для теста выслать (продукт совсем и даже очень не бесплатный)
D>4. Может и не все вспомнил... Читайте что можна тут: HeapAgent. Если заинтересовало, могу для теста выслать (продукт совсем и даже очень не бесплатный)
Давайте меняться, меняю агент на последний смартхип!
). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
