Как я могу узнать причину root дампа ядра SIGTRAP из GDB - PullRequest
0 голосов
/ 25 февраля 2020

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

Вывод GDB при сбое моего приложения



    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Core was generated by `/home/greystone/myapp/myapp'.
    Program terminated with signal SIGTRAP, Trace/breakpoint trap.
    #0  0x00007f5d3a435afb in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    [Current thread is 1 (Thread 0x7f5cea3d4700 (LWP 14353))]
    (gdb) bt full
    #0  0x00007f5d3a435afb in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    No symbol table info available.
    #1  0x00007f5d3a435c6f in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    No symbol table info available.
    #2  0x00007f5d3a472742 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    No symbol table info available.
    #3  0x00007f5d3a42cab3 in g_main_context_new () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    No symbol table info available.
    #4  0x00007f5d3f4894c9 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) () from /opt/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Core.so.5
    No symbol table info available.
    #5  0x00007f5d3f4895a1 in QEventDispatcherGlib::QEventDispatcherGlib(QObject*) () from /opt/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Core.so.5
    No symbol table info available.
    #6  0x00007f5d3f266870 in ?? () from /opt/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Core.so.5
    No symbol table info available.
    #7  0x00007f5d3f267758 in ?? () from /opt/Qt5.9.2/5.9.2/gcc_64/lib/libQt5Core.so.5
    No symbol table info available.
    #8  0x00007f5d3efa76ba in start_thread (arg=0x7f5cea3d4700) at pthread_create.c:333
    __res = 
    pd = 0x7f5cea3d4700
    now = 
    unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140037043603200, 4399946704104667801, 0, 140033278038543, 8388608, 140037073195984, -4344262468029171047, -4344357617020880231}, mask_was_saved = 0}}, 
      priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
    not_first_call = 
    pagesize_m1 = 
    sp = 
    freesize = 
    __PRETTY_FUNCTION__ = "start_thread"
    #9  0x00007f5d3e43c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
    No locals.

Решения, которые я пробовал

  • Поиск topi c, связанный с SIGTRAP
  • Люди сказали, что это режим отладки и есть где-то в коде точка останова. Однако мое приложение скомпилировано в режиме выпуска без точки останова.
Обработчик сигналов перехвата и игнорирование SIGTRAP
  • Безуспешно, я могу игнорировать только SIGTRAP, отправленный командой kill - 5 пид ". Когда SIGTRAP происходит случайным образом во время выполнения, мое приложение по-прежнему аварийно завершается * C Условия гонки API
  • Двойная проверка действия удаления массива и двойная проверка значения присваивания для индекса вне границ массива
Проверка сигналов и слотов
  • Мое приложение построено на платформах Qt как приложение GUI, я проверил много сигналов и слотов, но не знаю, как они связаны с дампом ядра SIGTRAP.
Проверка исключений для opencv
  • Я использую opencv для задач обработки изображений. Я проверил на исключительные случаи
Общая память
  • Память, совместно используемая между основным процессом и подпроцессами, была тщательно проверена

Пример кода Много кода в моем приложении, но потому что GDB не дает мне точно, где это происходит, поэтому я не знаю, какой код я должен поделиться. Если вам нужна проверка предложений, скажите, какую часть кода вы хотели бы проверить. Мое приложение состоит из следующих частей:

  • Mysql в C API mysql 5.7.29
  • Пользовательский интерфейс (много) в рамках Qt Framework 5.9.2
  • Обработка изображений с помощью opencv 2.4.9
  • Поток процессов в многопоточности с помощью инфраструктуры Qt 5.9.2

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

1 Ответ

0 голосов
/ 25 февраля 2020

для этого случая GDB не дает мне слишком много подсказок

GDB сообщает вам точно что случилось, вы просто не поняли этого.

Что происходит, так это то, что некоторый код в libglib называется g_logv(..., G_LOG_FLAG_FATAL, ...), который в конечном итоге вызывает _g_log_abort(), который выполняет команду int3 (точка отладки).

Вы должны быть в состоянии (gdb) x/i 0x00007f5d3a435afb и см. эту инструкцию.

Похоже, g_main_context_new(), возможно, не удалось выделить память.

В любом случае, вы должны посмотреть в приложении stderr протоколы по причине libglib завершает вашу программу (фактически, libglib вызывает эквивалент abort, потому что некоторые предварительные условия не выполнены).

...