GDB отладка coredump с отсутствующими таблицами символов для определенного стека вызовов

Question

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

#0 BIH::intersectRay<VMAP::MapRayCallback> (this=0x7f47b8339608, r=..., intersectCallback=..., maxDist=@0x7f493af8383c: 0, stopAtFirst=true, los=<optimized out>) at ../BIH.h:223 
#1 0x000000307ff00000 in ??() 
#2 0x7ff0000000000000 in ??() 
#3 0x0000000000000030 in ??() 
#4 0x000000307ff00000 in ??() 
#5 0x7ff0000000000000 in ??() 
#6 0x0000000000000030 in ??() 
#7 0x000000307ff00000 in ??() 
#8 0x7ff0000000000000 in ??() 
#9 0x0000000000000030 in ??() 
#10 0x000000307ff00000 in ??() 
#11 0x7ff0000000000000 in ??() 
#12 0x0000000000000030 in ??() 
#13 0x000000307ff00000 in ??() 
#14 0x7ff0000000000000 in ??() 
#15 0x0000000000000030 in ??() 
#16 0x000000307ff00000 in ??() 
#17 0x7ff0000000000000 in ??() 
#18 0x0000000000000030 in ??() 
#19 0x000000307ff00000 in ??() 
#20 0x7ff0000000000000 in ??() 
#21 0x0000000000000030 in ??() 
#22 0x000000307ff00000 in ??() 
.... 
#749 0x7ff0000000000000 in ??() 
#750 0x0000000000000030 in ??() 
#751 0x000000307ff00000 in ??() 
#752 0x7ff0000000000000 in ??() 
#753 0x0000000000000030 in ??() 
#754 0x000000307ff00000 in ??() 
#755 0x7ff0000000000000 in ??() 
#756 0x0000000000000030 in ??() 
#757 0x000000307ff00000 in ??() 
#758 0x7ff0000000000000 in ??() 
#759 0x0000000000000030 in ??() 
#760 0x000000307ff00000 in ??() 
#761 0x7ff0000000000000 in ??() 
#762 0x0000000000000030 in ??() 
#763 0x000000307ff00000 in ??() 
#764 0x03010102464c457f in ??() 
#765 0x0000000000000000 in ??()` 


(gdb) info frame 0 
Stack frame at 0x7f493af83830: 
rip = 0x930f0b in BIH::intersectRay<VMAP::MapRayCallback> (../BIH.h:223); saved rip = 0x307ff00000 
called by frame at 0x7f493af83838 
source language c++. 
Arglist at 0x7f493af83438, args: this=0x7f47b8339608, r=..., intersectCallback=..., maxDist=@0x7f493af8383c: 0, stopAtFirst=true, los=<optimized out> 
Locals at 0x7f493af83438, Previous frame's sp is 0x7f493af83830 
Saved registers: 
    rbx at 0x7f493af837f8, rbp at 0x7f493af83800, r12 at 0x7f493af83808, r13 at 0x7f493af83810, r14 at 0x7f493af83818, r15 at 0x7f493af83820, rip at 0x7f493af83828 

#1 0x000000307ff00000 in ??() 
No symbol table info available. 
(gdb) info frame 1 
Stack frame at 0x7f493af83838: 
rip = 0x307ff00000; saved rip = 0x7ff0000000000000 
called by frame at 0x7f493af83840, caller of frame at 0x7f493af83830 
Arglist at 0x7f493af83828, args: 
Locals at 0x7f493af83828, Previous frame's sp is 0x7f493af83838 
Saved registers: 
    rip at 0x7f493af83830 

#2 0x7ff0000000000000 in ??() 
No symbol table info available. 
(gdb) info frame 2 
Stack frame at 0x7f493af83840: 
rip = 0x7ff0000000000000; saved rip = 0x30 
called by frame at 0x7f493af83848, caller of frame at 0x7f493af83838 
Arglist at 0x7f493af83830, args: 
Locals at 0x7f493af83830, Previous frame's sp is 0x7f493af83840 
Saved registers: 
    rip at 0x7f493af83838 

#3 0x0000000000000030 in ??() 
No symbol table info available. 
(gdb) info frame 3 
Stack frame at 0x7f493af83848: 
rip = 0x30; saved rip = 0x307ff00000 
called by frame at 0x7f493af83850, caller of frame at 0x7f493af83840 
Arglist at 0x7f493af83838, args: 
Locals at 0x7f493af83838, Previous frame's sp is 0x7f493af83848 
Saved registers: 
    rip at 0x7f493af83840 

#4 0x000000307ff00000 in ??() 
No symbol table info available. 
(gdb) info frame 4 
Stack frame at 0x7f493af83850: 
rip = 0x307ff00000; saved rip = 0x7ff0000000000000 
called by frame at 0x7f493af83858, caller of frame at 0x7f493af83848 
Arglist at 0x7f493af83840, args: 
Locals at 0x7f493af83840, Previous frame's sp is 0x7f493af83850 
Saved registers: 
    rip at 0x7f493af83848 

Код составлен с использованием -g -fvar-tracking -O2 -march=native.

У меня были разные дампы для различных сбоев, которые работали на всех таблицах символов и предоставляли соответствующие стеки вызовов и информацию, но по какой-то причине этот конкретный сбой является загадочным.

Одна вещь, которую я заметил, это повторяющиеся снова и снова повторяющиеся номера адресов, может ли быть какой-то бесконечный цикл или рекурсия каких-то сортов, которые развращают или переполняют стек?
Если это так, есть ли способ получить верхнюю часть большинства функций в стеке вызовов (например, любой способ перейти выше кадра # 765 или получить функции, вызванные до того, как было запущено переполнение)?

Я не могу установить $sp или jump на любой адрес из-за этого, я не могу отлаживать и проходить через живую программу, просто проанализируйте дамп ядра.
Я не могу повторить этот крах, это происходит на производстве время от времени. Также не может быть и речи.

Есть ли какие-либо параметры компилятора g++ или gdb флаги, которые могут мне помочь?
Любые указатели на то, как отлаживать такую ​​проблему, оцениваются (если возможно вообще).

Answer 1

Я понятия не имею, как отлаживать дамп ядра, поскольку стек вызовов отсутствуют символы Информация по какой-то причине

Часть 1:

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

Если вы использовали --build-id во время связи, или если ваш НКУ настроен использовать этот флаг компоновщика по умолчанию, то вы можете проверить двоичные матчи (или не соответствует) core с помощью этой процедуры:

readelf -n /path/to/binary 

Это должно производить вывод, подобный:

$ readelf -n /bin/sleep 

Displaying notes found at file offset 0x00000254 with length 0x00000020: 
    Owner     Data size Description 
    GNU     0x00000010 NT_GNU_ABI_TAG (ABI version tag) 
    OS: Linux, ABI: 2.6.24 

Displaying notes found at file offset 0x00000274 with length 0x00000024: 
    Owner     Data size Description 
    GNU     0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) 
    Build ID: c266a51e4b85b16ca17bff8328f3abeafb577b29 

Моделировочных Идентификационной строку c266a51e4b85b16ca17bff8328f3abeafb577b29 является выходом вы заботитесь о. Если предположить, что двоичный файл имеет его, установить elfutils пакет, а затем использовать

eu-unstrip -n --core /path/to/core 

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

Вывод должен выглядеть следующим образом:

$ eu-unstrip -n --core /tmp/core 
0x400000+0x208000 c266a51e4b85b16ca17bff8328f3abeafb577b29@0x400284 - - [exe] 
0x7ffca5721000+0x1000 9c7cbcf6c957d8fc8e55b45a3c7a1556b38a3097@0x7ffca5721340 . - linux-vdso.so.1 
0x7f491ad5a000+0x2241c8 d0f537904076d73f29e4a37341f8a449e2ef6cd0@0x7f491ad5a1d8 /lib64/ld-linux-x86-64.so.2 /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ld-linux-x86-64.so.2 
0x7f491a995000+0x3c42c0 cf699a15caae64f50311fc4655b86dc39a479789@0x7f491a995280 /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so libc.so.6 

Выше Вы можете видеть, что это core свалка была фактически производимого /bin/sleep.

Если исполняемый файл build-id в core не соответствует вашему двоичному файлу, вам нужно будет найти двоичный файл с идентификатором сборки, соответствующим вашему core, прежде чем вы сможете извлечь правильную трассировку стека аварий в GDB.

Часть 2:

Если бинарный делает соответствует core, то весьма вероятно, что стек просто коррумпированы (например, из-за переполнения буфера стека).

valgrind не может быть.

Valgrind является исключительно слабым при обнаружении повреждения стека в любом случае.

Современное состояние при отладке этих проблем составляет Address Sanitizer, что значительно быстрее и может быть достаточно быстрым для запуска в процессе производства.

Если дезинфицированная двоичная система не является достаточно быстрой для использования в производстве, вы можете настроить ее таким образом, чтобы она обрабатывала некоторые подмножества входов в «теневом режиме» (бинарные прогоны, но его выход отбрасывается). Любые усилия, которые вы вложили в такую ​​настройку, скорее всего, обнаружат 10 новых ошибок и сэкономят вам значительные будущие усилия по отладке.