У меня есть приложение на производстве, которое через очень непредсказуемые промежутки времени (иногда реже одного раза в неделю, реже одного раза в час) приводит к ошибкам сегмента.
После того, как мне сначала пришлось настроить его на создание дампов ядра, у меня теперь есть один. Однако я вообще не получаю никаких символов, поэтому это бесполезно.
Я пытался сравнивать идентификаторы сборки с исполняемым файлом, который его произвел, хотя, основываясь на временах, я почти уверен, что у меня правильный, но даже это не может быть извлечено, кажется.
$ eu-unstrip -n --core /path/to/core
0x7ffd56d9e000+0x1000 a6c873a47c39e0b4c46a8e56aace0675e6d58d33@0x7ffd56d9e7d0 . - linux-vdso.so.1
Который, по-видимому, не является идентификатором [exe], который я видел в примерах этого.
Могу ли я что-нибудь сделать, кроме загрузки gdb, создания файла символов / path / to / my / binary и необходимости признать, что этот дамп ядра для меня бесполезен?
EDIT:
gdb -ex где производит то, что похоже на трассировку стека. Чем это отличается от запуска файла символов?
У меня есть несколько библиотек, которые я включаю в качестве исходных файлов, остальные динамически связаны.
в exe есть идентификатор сборки согласно read elf.