GDB помогает анализировать ядро ​​

Question

Один из нашего кода генерируют файл дамп При попытке проанализировать ядро ​​с помощью GDB с ниже командами GdB programe_name сердечника

Я не смог получить tarce с командой трассировки становится ниже

#4 0x20202020 in ??() 
    #5 0x20202020 in ??() 
    #6 0x20202020 in ??() 
    #7 0x20202020 in ??() 
    #8 0x20202020 in ??() 
    #9 0x20202020 in ??() 
    #10 0x20202020 in ??() 
    #11 0x20202020 in ??() 
    #12 0x20202020 in ??() 
    #13 0x20202020 in ??() 
    #14 0x20202020 in ??() 
    #15 0x20202020 in ??() 
    #16 0x20202020 in ??() 
    #17 0x20202020 in ??() 
    #18 0x20202020 in ??() 
    #19 0x20202020 in ??() 

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

Answer 1

похоже, ваш стек был «хрустел» - то есть, переписывается с некоторыми данными, S не может быть там.

0x20202020 - это четыре пробела в ASCII, поэтому стек был перезаписан строкой символов с большим количеством пробелов.

Ищите массив (или переменную), который вы читаете (или копируете символы в); скорее всего, вы читаете/копируете больше данных, чем ожидали в этот массив/переменную.

Чтобы избежать такого рода вещей в будущем, использовать одну из форм, что позволяет ограничить количество чтения/скопированное до размера целевой области:

fread 
fgets 
strncpy 

Вы можете также принять Посмотрите на ответы Reading in a variable length string user input in C Как относительно безопасные способы защитить себя при чтении данных неизвестной длины в буфер.