Можно ли напрямую идентифицировать неисправный код, который перезаписал весь стек?

Проще говоря, если программа на C ++ выполняет следующую функцию (скажем, в Windows 7, скомпилированную с любой версией VS), затем происходит сбой, и вы присоединяете отладчик с WER или WER генерирует аварийный дамп, а затем анализирует этот аварийный дамп. ,

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

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

void bye_bye_stack() {
int local = 42;
int* stackaddr = &local;
while(time(NULL) != NULL) { // prevent optimizations via call to time()
++stackaddr; // stack grows towards smaller addresses, so increasing the pointer will point to info we already put on the stack
*stackaddr = local; // destroy stack content
// program will (likely) crash here once we reach a read-only page
}
}

2

Решение

Как правило, уничтожая стек, как вы делаете, вы уничтожаете «стек вызовов», то есть информация о ранее вызванных подпрограммах исчезнет. Однако, если вы запустите нарушение доступа / сегментации изнутри этой подпрограммы, указатель инструкции, где это произошло, будет сохранен, указывая на эту подпрограмму.

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

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

1

Другие решения

Это не прямой ответ на ваш вопрос.

Однако, когда я испытывал перезапись стека, я использовал для запуска утилиту gflags, которая сразу же подтверждала бы при перезаписи стека.

Gflags предоставлен Microsoft.

1

Это действительно зависит. Обратные ссылки, предоставленные в аварийном дампе, напрямую зависят от информации, хранящейся в стеке. Обычно это означает, что вы НЕ МОЖЕТЕ доверять обратному следу, когда подозреваете повреждение стека.

Предоставленная вами функция очень вероятно повредит стек WHOLE и затем вызовет исключение, когда вы превысите пределы сегмента или достигнете памяти, которая недоступна для процесса. В это время в стеке ничего не будет указывать на подозреваемого.

-1
По вопросам рекламы [email protected]