Отладка обработчиков сигналов из основного файла с помощью GDB - PullRequest
Новая
       41

Отладка обработчиков сигналов из основного файла с помощью GDB

0 голосов
/ 16 апреля 2020

Я отлаживаю основной файл, в котором получил нарушение сегмента. Согласно файлу ядра, это происходит, когда программа пытается получить доступ к действительному разделу памяти. У нас есть журнал, который показывает, что ранее был звонок на madvise(addr,size,MADV_DONTNEED), где этот адрес находился в заданном диапазоне. Это означает, что он, вероятно, был заменен во время вызова.

Кроме того, при отладке файла ядра, если мы делаем дамп структуры $_siginfo, он показывает, что si_signo = 11 и si_addr = 1234, где 1234 - это pid процесса. В настоящее время мы подозреваем, что мы получили SIGBUS, и кто-то зарегистрировал обработчик, который вызывает SEGV.

Итак, два вопроса: - во-первых, возможно ли в GDB просмотреть стек обработчика сигнала ? У меня сложилось впечатление, что обработчик сигнала будет использовать стек процессов, но необработанный дамп пространства стека не показывает никаких доказательств того, что это так (я подозреваю, что кто-то явно зарегистрировал стек обработчика сигналов в этом случае),

И, во-вторых, есть ли способ в GDB определить из файла ядра, какой обработчик сигнала зарегистрирован для определенного сигнала? info signal не говорит мне об этом.

----- РЕДАКТИРОВАТЬ ----------

некоторые дополнительные сведения: это приложение на пользовательском пространстве arm32 bit , GDB показывает: 

(gdb) list
234     port_get_port_info (handle_t handle)
235     {
236         port_info_t *port_info;
237         int rc;
238
239         rc = id_to_ctx(port_db, handle, (void **)&port_info);

(где 239 - строка сбоя - обратите внимание, что port_db - это глобальный объект на странице, который предполагалось заменить, поэтому мы ожидаем, что здесь SIGBUS) 

(gdb) info inferior
  Num  Description       Executable
* 1    process 9820      /home/dev/ws1/fuzzy_bunny

(gdb) p $_siginfo
$1 = {
  si_signo = 11,
  si_errno = 0,
  si_code = 0,
  _sifields = {
    _pad = {9820, 0 <repeats 28 times>},
    ...
    _sigchld = {
      si_pid = 9820,
      si_uid = 0,
      si_status = 0,
      si_utime = 0,
      si_stime = 0
    },
    _sigfault = {
      si_addr = 0x265c
    },
  }
}

И: 

(gdb) bt 1
#0  0xf76e041c in port_get_port_info (handle=4278190136) at /home/dev/ws1/code/fuzzy_bunny/src/port_api.c:239
(More stack frames follow...)

Таким образом, обратная трассировка не показывает обработчик сигнала, что мне и нужно увидеть в данный момент. 

(gdb) info registers
r0             0x22a564 2270564
r1             0xff000038       4278190136
r2             0xee007574       3993007476
r3             0x0      0
r4             0x0      0
r5             0xee007758       3993007960
r6             0xff000038       4278190136
r7             0x6      6
r8             0xee007760       3993007968
r9             0xee007758       3993007960
r10            0xee007608       3993007624
r11            0x2364418        37110808
r12            0xf78da92c       4153256236
sp             0xee007568       0xee007568
lr             0xf76dc37c       -143801476
pc             0xf76e041c       0xf76e041c <port_get_sb+60>
cpsr           0x8f0010 9371664
fpscr          0x80000010       -2147483632

и asm: 

   x0xf76e0414 <port_get_sb+52>         ldr    r0, [pc, #196]  ; 0xf76e04e0 <port_get_sb+256>                                                       x
   x0xf76e0418 <port_get_sb+56>         add    r2, sp, #12                                                                                              x
b+>x0xf76e041c <port_get_sb+60>         ldr    r0, [pc, r0]                                                                                             x
   x0xf76e0420 <port_get_sb+64>         bl     0xf76cc8b4 <id_to_ctx@plt>                                                                       x

Опять же, я ищу способ увидеть, что происходит в обработчике сигналов из GDB ...

...