多线程GDK Cairo应用在set_source_pixbuf处偶发崩溃排查求助

问题描述 #

我有一个使用GDK Cairo的多线程C++应用（采用Glade作为UI框架），点击“保存”按钮的特定条件下会偶发崩溃，大部分段错误都出现在Gdk::Cairo::set_source_pixbuf(cr, image, 0, 0);行，偶尔也会在其他行触发。

相关代码如下：

std::string DefectWindowBase::save_image(Glib::RefPtr<Gdk::Pixbuf>& image, std::string filename) {
    int width  = image->get_width();
    int height = image->get_height();

    Cairo::Format format = (image->get_has_alpha() ? Cairo::FORMAT_ARGB32 : Cairo::FORMAT_RGB24);
    auto surface         = Cairo::ImageSurface::create(format, width, height);
    auto cr              = Cairo::Context::create(surface);
    Gdk::Cairo::set_source_pixbuf(cr, image, 0, 0);
    cr->rectangle(0, 0, width, height);
    cr->fill();

    sig_draw_rawoverlay.emit(cr, width, height, false);

    // Scale will not be drawn if it is not enabled
    sig_draw_scale.emit(cr, width, height);

    bool pathsHaveExternalFile = (mJobFilePaths.filePaths().size() >= 2);

    // Create a worker to save the local and remote images to file
    workers.push_back(std::make_shared<ImageWriteWorker>(surface, mJobFilePaths.getMainFilePath(),
                                                         pathsHaveExternalFile ? mJobFilePaths.filePaths().at(1) : "",
                                                         filename));

    // Connect the workers "completed" signal to a tidy up function to clean up the memory used after the images are saved
    workers.back()->sig_completed.connect(
        sigc::bind(sigc::mem_fun(this, &DefectWindowBase::tidy_worker), workers.back()));

    return filename;
}

当前GDB调试显示libgdk3.0.0触发段错误，但缺少符号表。希望了解可能的崩溃原因，以及进一步调试的建议，准确定位根因。

可能的崩溃原因 #

• GDK/GTK线程安全违规：GDK、GTK的核心API均不支持多线程直接调用，所有涉及Pixbuf、Cairo绘图的操作必须在UI主线程执行。如果save_image函数本身在非UI线程调用，或者信号sig_draw_rawoverlay/sig_draw_scale的处理函数在子线程运行，会直接引发内存访问错误。
• Pixbuf生命周期冲突：image是引用传递的Glib::RefPtr<Gdk::Pixbuf>，若在save_image使用它的过程中，其他线程（比如UI线程）对该Pixbuf执行了销毁、修改操作，会导致set_source_pixbuf访问已释放的内存。
• Cairo资源竞争：如果ImageWriteWorker子线程处理Surface的同时，原线程对Surface进行了修改，或者多个线程共享同一个Cairo Context/Surface，会触发段错误。
• 容器访问越界风险：mJobFilePaths.filePaths().at(1)依赖容器大小判断，但如果其他线程在判断后、访问前修改了filePaths()，会导致下标越界，间接引发崩溃。
• 信号处理的线程上下文问题：sig_draw_rawoverlay和sig_draw_scale的回调函数若包含GDK操作，且不在UI线程执行，会违反线程规则导致崩溃。

进一步调试建议 #

• 安装GDK调试符号：安装对应系统的GDK调试包（如Debian/Ubuntu的libgdk3.0.0-dbgsym），让GDB能输出完整的崩溃调用栈，定位到libgdk内部的具体出错点。
• 强制UI线程执行绘图逻辑：将save_image中从创建Surface到信号发射的所有绘图代码，通过Glib::signal_idle().connect()放到UI主线程执行，确保GDK操作符合线程要求。
• 保护Pixbuf的线程访问：对image的读写操作添加互斥锁，避免多线程同时访问；或者在save_image开头创建Pixbuf的副本（image->copy()），使用副本进行后续操作，隔离原对象的生命周期变化。
• 验证线程上下文：在save_image和信号回调函数中添加日志，打印当前线程ID（Glib::Thread::self()->get_id()），确认是否在UI线程执行。
• 内存检测工具排查：用valgrind --leak-check=full --track-origins=yes运行程序，捕捉内存访问错误、野指针等问题，获取更精准的错误位置。
• 隔离Cairo Surface资源：给ImageWriteWorker传递Surface的副本（surface->create_similar()），避免子线程与原线程共享同一Surface导致竞争。
• 容器访问加锁：对mJobFilePaths.filePaths()的访问添加互斥锁，确保判断容器大小和访问元素的操作是原子性的，防止越界。

内容的提问来源于stack exchange，提问作者Phippsy