C++ 如何找出GDB SIGTRAP核心转储的根本原因

我的应用程序随机（每天一次）崩溃，我尝试了几种方法来找出原因，但没有成功。 对于其他的内核转储或分段错误情况，我可以通过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.

我尝试过的解决方案

• 与SIGTRAP相关的搜索主题
• 人们说它处于调试模式，在代码集的某个地方有断点。但是，我的应用程序是在发布模式下编译的，没有断点
• 捕获信号处理程序并忽略SIGTRAP
• 没有成功，我只能忽略“kill-5PID”发送的信号陷阱。由于SIGTRAP在运行时随机发生，我的应用程序仍然崩溃
• 修复代码中的内存泄漏
• 使用nullptr初始化指针
• 仔细检查mysql C API竞争条件
• 双击“删除数组操作”并双击“为数组边界外的索引赋值”
• 检查信号和插槽
• 我的应用程序是建立在Qt框架上的GUI应用程序，我检查了很多信号和插槽，但不知道它们与SIGTRAP核心转储有什么关系
• 检查opencv的异常
• 我使用opencv进行图像处理任务。我查过例外情况
• 共享内存
• 仔细检查主进程和子进程之间共享的内存

示例代码
我的应用程序中有很多代码，但因为gdb没有告诉我具体发生在哪里，所以我不知道应该共享哪些代码。如果您需要它来检查建议，请告诉我您想检查代码的哪一部分。我的应用程序有以下几个部分

• C api Mysql 5.7.29中的Mysql
• Qt框架5.9.2的用户界面（alot）
• 使用opencv 2.4.9进行图像处理
• 基于Qt框架5.9.2的多线程处理流程

如果有任何想法，请与我分享一些关键字，然后我可以搜索它并应用到我的应用程序。谢谢你的帮助

对于这种情况，gdb不要给我太多提示

GDB会告诉你到底发生了什么，你只是不明白而已

发生的事情是，

libglib

中的一些代码调用了

g_logv（…，g_LOG_FLAG_FATAL，…）

，它最终调用了

\u g_LOG_abort（）

，执行

int3

（调试断点）指令

您应该能够

（gdb）x/i 0x00007f5d3a435afb

并查看该说明

看起来

g\u main\u context\u new（）

可能无法分配内存

---

在任何情况下，您都应该查看应用程序

stderr

日志，了解

libglib

终止程序的原因（实际上，

libglib

调用了一个与

abort

相当的函数，因为某些先决条件失败）。

我没有完全理解gdb输出，这是对的。libqtcore使用libglib库，我的源代码没有直接调用它。这是

（gdb）x/i 0x00007f5d3a435afb=>0x7f5d3a435afb:jmpq 0x7f5d3a435a57的输出这次，保存在/var/sys/log中的stderr日志显示警告
[91781.798205]陷阱：ProcessCenter[14353]陷阱int3 ip:7f5d3a435afb sp:7F5CEA38B0错误：0在libglib-2.0中。so.0.4800.2[7f5d3a3e5000+10f000]
感谢您的建议，我将试图找出为什么g_main_context_new不能分配新内存