Как увеличить вероятность совпадения дампов ядра Linux с символами?
У меня очень сложное кроссплатформенное приложение. Недавно мы с моей командой проводили стресс-тесты и столкнулись с несколькими сбоями (и сопровождающими их дампами). Некоторые из этих дампов ядра очень точны и показывают мне точное место, где произошел сбой, примерно с 10 или более кадрами стека. У других иногда есть только один кадр стека с ?? это единственный символ!
Я хотел бы знать следующее:
- Есть ли способ увеличить вероятность того, что дампы ядра будут указывать в правильном направлении?
- Почему нет? • Количество фреймов стека, о которых сообщается, согласовано?
- Какие-либо рекомендации по управлению дампами ядра.
Вот как я компилирую двоичные файлы (в режиме выпуска):
- Компилятор и платформа: g ++ с glibc-2.3.2 -95,50 в CentOS 3.6 x86_64 - Это помогает мне поддерживать совместимость со старыми версиями Linux.
- Все файлы компилируются с флагом -g.
- Отладочные символы удаляются из окончательного двоичного файла и сохраняются в отдельном файле.
- Когда у меня есть дамп ядра, я использую GDB с исполняемым файлом, который создал ядро, и файлом символов. GDB никогда не жалуется на несоответствие между ядром / двоичным кодом / символами.
Однако иногда я получаю дампы ядра без каких-либо символов! Понятно, что я связываюсь с неотладочной версией libstdc ++ и libgcc, но было бы хорошо, если бы хотя бы трассировка стека показывала мне, где в моем коде возник ошибочный вызов инструкции (хотя в конечном итоге он может оканчиваться на ??).