Уж незнаю в какой этот форум, модераторы если что поправят.
Опишу ситуацию, есть некоторое распределённое/клиент серверное приложение, и живёт в нём хитрый и злой мега баг. Хитрый мега баг проявляется тем, что иногда срёт в чужую память нулями (любя мы называем его засранцем ). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый 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
По количество ноликов — интересная идея, буду теперь их считать
). А хитрый и злой он потому, что мы только видим его последствия — испорченная память, и НИКОГДА не видим кто именно какает. В приложении при каждом системном исключении создаются дампы памяти, так что мы контролируем каждый AV (создаём дампы внутри Vectored Exceptions Handler-а). Много гоняли под Application Verifier, не очень много под Dev Partner-ом, под Dev Partner-ом не можем сильно гонять, так как он убивает всю производительность. Собсно нужны какие то принципиальные идеи как его может быть и как енту каку выловить.
