Определение точной строки в исходном коде в аварийном дампе ядра - PullRequest
Новая
       13

Определение точной строки в исходном коде в аварийном дампе ядра

0 голосов
/ 23 марта 2011

Привет! Я запускаю тест bi-di 'iperf' на интерфейсе, используя мой драйвер.Шаги для воспроизведения: bi-di I/O на одном интерфейсе (другой интерфейс не активен):

  • Запустить iperf -c -P 8 -t 100000 -I 10 на DUT
  • iperf -c с теми же параметрами, что и выше, от равноправного узла почти сразу (после того, как истекли первые 10 секунд 'iperf send') с 'iperf -s -w 256K' на обоих

Сбой непроисходит как таковое в драйвере, но в контексте 'iperf'.Я собираюсь скопировать и вставить трассировку стека: 

 PID: 8855   TASK: f7036550  CPU: 0   COMMAND: "iperf"
 #0 [c074bed0] crash_kexec at c0443233
 #1 [c074bf14] die at c04064d3
 #2 [c074bf44] do_page_fault at c062134b
 #3 [c074bf94] error_code (via page_fault) at c0405abb
    EAX: f5888100  EBX: 00000000  ECX: 00100100  EDX: 00200200  EBP: 00000001
    DS:  007b      ESI: f5888000  ES:  007b      EDI: cb614000
    CS:  0060      EIP: c05c4e94  ERR: ffffffff  EFLAGS: 00010046
 #4 [c074bfc8] net_rx_action at c05c4e94
 #5 [c074bfe4] __do_softirq at c042aa65
--- <soft IRQ> ---
 #0 [f281ac4c] do_softirq at c04073e5
 #1 [f281ac58] do_IRQ at c04074d9
 #2 [f281ac70] common_interrupt at c0405975
    EAX: 39383736  EBX: f281af4c  ECX: 00000428  EDX: 31303938  EBP: f378b042
    DS:  007b      ESI: f378b1c2  ES:  007b      EDI: 09fdb448
    CS:  0060      EIP: c04f1c07  ERR: ffffffba  EFLAGS: 00000202
 #3 [f281aca4] __copy_to_user_ll at c04f1c07
 #4 [f281acb0] memcpy_toiovec at c05bfecc
 #5 [f281acc4] skb_copy_datagram_iovec at c05c059b
 #6 [f281acf4] tcp_rcv_established at c05ef40a
 #7 [f281ad20] tcp_v4_do_rcv at c05f48c5
 #8 [f281ad54] tcp_prequeue_process at c05e6bdd
 #9 [f281ad5c] tcp_recvmsg at c05e90e2
#10 [f281ad9c] sock_common_recvmsg at c05bb1c4
#11 [f281adc0] sock_recvmsg at c05b8dc6
#12 [f281aea0] sys_recvfrom at c05ba6ab
#13 [f281af64] sys_recv at c05ba727
#14 [f281af80] sys_socketcall at c05bab52
#15 [f281afb8] system_call at c0404f44
    EAX: ffffffda  EBX: 0000000a  ECX: b6ba2340  EDX: 00014268
    DS:  007b      ESI: 00000000  ES:  007b      EDI: 09fbe630
    SS:  007b      ESP: b6ba2328  EBP: b6ba2378
    CS:  0073      EIP: 004ad410  ERR: 00000066  EFLAGS: 00000293
crash>

EIP на момент сбоя составляет net_rx_action:0xdd/19ca.Теперь я скомпилировал kernel-2.6.18-238 sources (исходную версию ОС, на которой работает DUT) и выполнил 'objdump -S ./net/core/dev.o > dev_o_dmp 'на ./net/core/dev.c, который имеет определение net_rx_acdtion ().Теперь в файле 'dev_o_dmp' net_rx_action() имеет множество встроенных определений и, следовательно, почему-то точно не отражает поток в исходном файле.В таком сценарии безопасно ли добавлять 0xdd к базовому адресу net_rx_action (say 32FF) => 340C .ie будет 340C номером строки, вызывающей сбой, вызывающей сбой 'kernel paging request error'

Любые советы/ рекомендации о том, как отладить эту проблему, очень помогли бы

1 Ответ

0 голосов
/ 28 марта 2011

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

Вы должны предположить, что номера строк, полученные с помощью этой техники, могут быть неправильными.При этом я часто использую эту технику в своей работе с ядром, и у меня еще не было проблем (стуки по дереву).Просто помните, что если вы столкнулись с чем-то, что просто не имеет смысла, у вас может быть плохой номер строки.

...