Начну издалека.
Скажем, устройство DCRT кучи известно. Есть структура _CrtMemBlockHeader, которая предшествует блоку, выделенному через new/malloc/calloc. Таким образом в отладчике легко проверить любой указатель на валидность (посмотреть на его заголовок и побегать по списку выделенных блоков).
Устройство релизной CRT кучи также можно изучить, благо CRT поставляется с исходными текстами.
А как устроены кучи Win32? Какие заголовки предшествуют блокам выделенной памяти? Это кому-нибудь известно? (У Рихтера ничего нет...)
А проблема такая. Приложение упало на RtlFreeHeap(). По дампу процесса установлено, что указатель передан в HeapFree() корректный. В смысле, что по нему находятся именно те данные, которые там и должны находиться. Нет сомнений, что указатель получен через HeapAlloc(). Интересно было бы проверить корректность заголовка этого указателя, либо как-то еще проверить его.
Буду очень благодарен за любую информацию по такой специфичной проблеме.
Здравствуйте alex_e, Вы писали:
AE>Интересно было бы проверить корректность заголовка этого указателя, либо как-то еще проверить его.
Похожая проблема у меня была. Оказалось что в выделенном блоке памяти посрредством new затирался служебный DWORD, находящийся до начала выделяемого блока. Затирался по моей вине, был выход за массив на 1 байт. Правда, это было в Борланде 5.02., ошибку искал долго.
Здравствуйте Oleg_M, Вы писали:
OM>Здравствуйте alex_e, Вы писали:
AE>> Интересно было бы проверить корректность заголовка этого указателя, либо как-то еще проверить его.
OM>Попробуй непосредственно перед RtlFreeHeap проверить "исправность" кучи в целом:
OM>if(_heapchk() !=_HEAPOK) OM>{ // Ой, беда.... OM>}
OM>Я знаю только эту "проверку правильности", если она выдает ошибку, просто двигаю этот if выше по коду, выясняя, OM>какая операция вызвала поломку кучи.
А если ты использовал свою кучу (пользовал HeapCreate()), то проверяй HeapValidate()
