如何调试基于GTK的Eclipse SWT应用界面挂起故障

第一步：优先抓挂起瞬间的混合栈，定位阻塞层级 #

挂起故障第一优先级是拿到准确的阻塞调用栈，不要只抓Java层栈：

• 应用卡住时，执行命令 jstack -m <Java进程PID> 抓取混合栈，该参数会同时输出Java调用栈、JNI层和native C/C++层的调用帧，可以直接看到_gtk_widget_destroy调用下方具体卡在什么逻辑：是卡在SWT自身的锁等待、GTK内部的信号分发、还是内核/X11通信调用。
• 连续抓取3次栈，每次间隔5秒，如果3次栈的native层栈顶位置完全一致，即可排除业务逻辑慢执行的可能，确定是死锁或系统调用无限等待类问题。

第二步：排查SWT UI线程违规调用问题 #

SWT的GTK实现对线程模型要求极严格，所有GTK相关操作必须在Display绑定的UI线程执行，这也是跨版本出现锁阻塞的高频原因：

• SWT的Platform.lock是GDK全局递归锁，一旦有非UI线程绕过checkWidget校验直接调用控件方法，就可能出现锁顺序反转，和dispose流程触发的锁请求形成死锁，这类问题在运行数小时后才触发的特征非常典型——后台任务刚好在dispose执行的窗口期抢占锁。
• 排查方式：通过字节码插桩或调试断点，监控所有Widget.checkWidget方法的调用线程，只要出现非Display线程调用该方法的记录，就是违规操作，优先修正这类跨线程控件访问逻辑。

第三步：排查GTK第三方模块阻塞 #

gtk_widget_destroy执行时会递归分发控件绑定的所有destroy、unrealize类信号，只要任意一个信号回调卡住，整个销毁流程就会一直阻塞，GTK交互式调试器同步挂起的现象，也符合GTK持有全局锁时执行信号回调卡住的特征：

• 优先排查三类问题高发模块：输入法模块（immodule）、GTK主题引擎、无障碍服务模块，SLES12默认预装的这三类模块版本老旧，和SWT的兼容性问题记录极多。
• 快速排除测试：启动应用前清空相关环境变量，禁用非必要GTK模块：

  export GTK_MODULES=""
  export GTK_IM_MODULE="gtk-im-context-simple"
  export GTK_THEME="Adwaita"
  export NO_AT_BRIDGE=1
  

  用上述环境变量启动应用跑稳定性测试，如果卡顿消失，逐个恢复变量定位具体是哪个模块导致的阻塞。
• 如果需要进一步看信号分发栈，可以用gdb attach到运行中的Java进程，卡住时执行bt full打印完整C栈，找g_signal_emit相关的调用帧，就能定位到具体是哪个模块注册的回调阻塞了流程。

第四步：排查X11服务通信阻塞 #

SLES12早期SP版本自带的Xorg存在已知的连接资源泄漏bug，应用长时间运行后，X11 socket通信会出现数分钟级的超时，而GTK控件销毁时需要同步向X server发送资源释放请求，就会表现为destroy流程卡住：

• 卡住时执行 strace -p <Java进程PID> -f -e trace=read,write,connect 跟踪系统调用，如果看到进程长期阻塞在对/tmp/.X11-unix/X0这个unix socket的读写操作上，就可以确定是X11通信层的问题。
• 这类问题优先给SLES12系统打全官方SP补丁，不要自行替换X11或GTK相关系统库，避免依赖链断裂。

临时规避方案 #

如果需要快速给用户修复，可先做两层规避：

• Eclipse 4.8及以上版本原生支持GTK3运行，启动时添加参数 --launcher.GTK_VERSION 3，强制使用系统自带GTK3运行，不要通过LD_LIBRARY_PATH自行加载非系统路径的GTK库，否则会因为glibc、依赖库版本不匹配引发更多异常。
• 对层级较深的Shell控件，不要在用户操作触发的同步流程里直接调用dispose，先将控件设置为隐藏，通过Display.timerExec延迟100ms再执行销毁，避开UI线程高负载期的锁冲突。

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