Я следовал инструкциям несколько похожего вопроса SO, но строка, которую я получаю, не имеет смысла.
У меня есть процесс apache, на котором работает php, скомпилированный с пользовательским расширением c php. Иногда я получаю ошибку сегментации и дамп ядра.
Это работает на обновленном сервере RHEL 6.5.
Я установил rpm-пакет отладочной информации для нашего расширения php. Открытие ядра и получение бт дает мне
(gdb) bt
#0 0x00007f7d7b99dd2f in ?? () from /etc/httpd/modules/libphp5.so
#1 0x00007f7d74783c81 in zif_x12_parse_file () from /usr/lib64/php/modules/x12_parser.so
#2 0x00007f7d7ba093b8 in ?? () from /etc/httpd/modules/libphp5.so
#3 0x00007f7d7b9e0500 in execute () from /etc/httpd/modules/libphp5.so
#4 0x00007f7d7b9ba70d in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#5 0x00007f7d7b968798 in php_execute_script () from /etc/httpd/modules/libphp5.so
#6 0x00007f7d7ba43d75 in ?? () from /etc/httpd/modules/libphp5.so
#7 0x00007f7d864b4bb0 in ap_run_handler ()
#8 0x00007f7d864b846e in ap_invoke_handler ()
#9 0x00007f7d864c3b30 in ap_process_request ()
#10 0x00007f7d864c09a8 in ?? ()
#11 0x00007f7d864bc6b8 in ap_run_process_connection ()
#12 0x00007f7d864c8977 in ?? ()
#13 0x00007f7d864c8c8a in ?? ()
#14 0x00007f7d864c8fbb in ap_mpm_run ()
#15 0x00007f7d864a0900 in main ()
Я предполагаю, что проблема на самом деле в нашем коде, а не в php на вершине стека. Итак, я получаю местоположение, которое так загружено
(gdb) info shared x12
From To Syms Read Shared Object Library
0x00007f7d7477ec20 0x00007f7d74784038 Yes /usr/lib64/php/modules/x12_parser.so
Вычитание местоположения начала загрузки из местоположения памяти стека
0x00007f7d74783c81 − 0x00007f7d7477ec20 = 5061
И пробив это в addr2line
$ addr2line -e /usr/lib/debug/usr/lib64/php/modules/x12_parser.so.debug 0x5061
/usr/src/debug/php-x12_parser-5.3.3/php-x12_parser/x12_parser.c:321
Но строки 321 нет в файле zif_x12_parse_file. И даже если бы это было так, я не думаю, что линия может рухнуть.
Так что же я сделал не так, рассчитывая линию крушения?