使用XCB开发窗口管理器遇无限循环Bug，如何排查修复？

错误含义明确 #

• XIO: fatal IO error 11：X服务器无法及时处理请求，大概率是请求发送过于频繁（比如无限循环批量发请求），或是资源耗尽导致。
• XIO: fatal IO error 104：X服务器主动断开连接，通常是因为客户端发送了无效请求，或长时间占用资源触发服务器终止连接。

诊断步骤 #

• 排查重父逻辑的循环问题
  重父窗口时最容易触发无限事件循环（比如MapRequest或ConfigureRequest反复触发）：
  • 给重父相关代码加日志，比如在处理MapRequest、调用xcb_reparent_window、创建框架窗口的前后打印窗口ID和操作类型，看是否有重复执行的情况。
  • 检查是否未给已重父的窗口做标记，导致每次收到MapRequest都重复执行重父逻辑。
• 监控X请求频率
  • 用xcb_trace工具跟踪所有X请求，看是否有大量重复的重父、窗口配置请求，定位到疯狂发送请求的代码段。
  • 在代码中加请求计数统计，每发送100次请求打印一次计数，观察计数是否异常飙升。
• 检查X资源泄漏
  • 用xlsclients或xwininfo查看系统中窗口数量是否随操作持续增长，排查是否创建框架窗口后未在客户端关闭时销毁。
  • 检查GC、Pixmap等资源是否在使用后未调用xcb_free_gc、xcb_free_pixmap释放。
• 验证事件处理逻辑
  • 确认事件循环是否是阻塞式（比如用xcb_wait_for_event），而非空转的轮询循环，避免无意义消耗资源。
  • 检查处理ConfigureNotify或ConfigureRequest时是否正确更新窗口状态，是否会导致事件反复触发。

修复方案 #

• 打破重父循环
  • 给已重父的客户端窗口添加自定义属性（比如WM_FRAME），处理MapRequest时先检查该属性，避免重复重父。
  • 重父后按正确顺序映射窗口：先映射框架窗口，再映射客户端窗口，避免客户端反复发送MapRequest。
• 控制X请求发送速率
  • 如果是布局调整、动画等场景的循环请求，加入usleep(1000)这类微小延迟，避免短时间发送大量请求压垮X服务器。
  • 避免在无限循环中无限制发送X请求，确保每个请求都有明确的触发条件。
• 正确管理X资源
  • 处理DestroyNotify事件时，同步销毁对应的框架窗口，释放关联的GC、Pixmap等资源。
  • 养成资源使用完即释放的习惯，避免资源累积耗尽。
• 修复事件处理逻辑
  • 用阻塞式事件循环代替轮询，减少空转消耗。
  • 处理ConfigureRequest时，正确计算框架窗口和客户端窗口的几何参数，更新后发送xcb_configure_window响应，避免客户端重复发送请求。

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