Проще говоря, если программа на 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
}
}
Как правило, уничтожая стек, как вы делаете, вы уничтожаете «стек вызовов», то есть информация о ранее вызванных подпрограммах исчезнет. Однако, если вы запустите нарушение доступа / сегментации изнутри этой подпрограммы, указатель инструкции, где это произошло, будет сохранен, указывая на эту подпрограмму.
Однако, если стек поврежден, и вы возвращаетесь из этой процедуры, будет очень трудно, если не невозможно, выяснить, что произошло.
Если вы пытаетесь выяснить, что произошло, я предлагаю использовать инструмент отладки, чтобы выяснить, где стек «разбит». Если вы намерены уничтожить доказательства выполнения, убедитесь, что вы «выпрыгнули» или «вернулись» из этой процедуры, не вызывая исключения.
Это не прямой ответ на ваш вопрос.
Однако, когда я испытывал перезапись стека, я использовал для запуска утилиту gflags, которая сразу же подтверждала бы при перезаписи стека.
Это действительно зависит. Обратные ссылки, предоставленные в аварийном дампе, напрямую зависят от информации, хранящейся в стеке. Обычно это означает, что вы НЕ МОЖЕТЕ доверять обратному следу, когда подозреваете повреждение стека.
Предоставленная вами функция очень вероятно повредит стек WHOLE и затем вызовет исключение, когда вы превысите пределы сегмента или достигнете памяти, которая недоступна для процесса. В это время в стеке ничего не будет указывать на подозреваемого.