来自 gdk_window_get_frame_clock 的 SIGABRT 信号答案

【问题标题】：SIGABRT signal from gdk_window_get_frame_clock来自 gdk_window_get_frame_clock 的 SIGABRT 信号
【发布时间】：2014-10-20 05:12:53
【问题描述】：

我对 GDK/GTK 相当陌生，但我正在尝试使一些 C 代码线程安全。（它非常大，否则我会在这里发布。）我正在做一些压力测试，GDB 因错误而停止：程序收到信号 SIGABRT，已中止。该程序在名为 gdk_window_get_frame_clock 的函数中停止，根据 GDK 文档，该函数是用于同步屏幕重绘的低级函数。堆栈跟踪只显示“0x0 in ??”为来电者。有谁知道这里发生了什么或者我可以从哪里开始搜索？我完全迷惑了。

【问题讨论】：

需要比这更多的信息。查看 gdb 的堆栈跟踪，找出问题发生时您编写的代码中发生了什么，然后从那里开始。
不能直接从其他线程调用GTK/GDK函数。您是否通过gdk_threads_enter()/gdk_threads_leave() 或等效函数正确锁定了来自其他线程的所有访问？
应用程序通过创建一个新的工作线程来设置自己，以便在执行期间执行复杂的计算以及重新绘制。主线程处理用户交互。这几乎可以肯定是一种竞争条件。我正在使用 POSIX 线程和互斥锁来控制对我的应用程序变量的访问。我会尝试设置关键部分并在有机会时回帖。

标签： c multithreading gtk gdk

【解决方案1】：

切勿从包含 glib 或 gtk 主循环的线程之外的其他线程中绘制任何内容。使用g_idle_add、g_timeout_add 或基于GSource 的自定义挂钩从辅助线程中排队UI 更改（这些是线程安全的！）

【讨论】：

谢谢！这行得通。据我所知，GDK 2 允许 gdk_threads_enter/gdk_threads_leave 方法从单独的线程中锁定 GDK 资源。但是，GDK 3 没有。现在我正在使用 g_idle_add 调用一个函数来排队主窗口重绘。这会导致 CPU 使用率过高，但这是一个很好的起点。