PJProject视频通话应用中的死锁问题分析与解决

问题背景

在PJProject 2.14.1版本的视频通话应用(vidgui)中，开发人员发现了一个严重的稳定性问题：当两台设备之间反复进行视频通话建立和挂断操作时，视频功能会出现挂起现象。具体表现为视频流停止更新，但音频连接仍能正常工作。

问题现象

该问题在以下场景中可稳定复现：

1. 设备A向设备B发起视频通话
2. 设备B接听后等待一段时间并挂断
3. 设备B向设备A发起视频通话
4. 设备A接听后等待一段时间并挂断
5. 重复上述过程约10次后，视频功能即会出现挂起

通过调试发现，当问题发生时，视频时钟回调函数on_clock_tick不再被调用，表明视频处理流程已被阻塞。

技术分析

通过深入调试和堆栈分析，发现问题涉及两个关键线程的交互：

1. 视频接收线程：负责处理接收到的RTP数据包，调用on_rx_rtp函数进行视频帧解码
2. 视频时钟线程：定时触发的on_clock_tick回调，负责视频帧的编码和发送

死锁发生的具体位置：

• 视频接收线程在decode_frame函数中持有了流媒体组的锁(stream->grp_lock)
• 同时，视频时钟线程在transport_send_rtp函数中尝试获取ICE传输层的锁(ice_st->grp_lock)

根本原因

进一步分析发现，这个问题实际上是由应用程序层的一个自定义锁引起的。开发人员曾在PJProject 2.13版本中为规避挂断按钮点击时的挂起问题，在应用层添加了一个锁机制。然而这个锁在2.14.1版本中未能正确释放，导致在新呼叫建立时出现死锁。

值得注意的是，PJProject 2.14.1版本本身已经修复了挂断时的稳定性问题，不再需要应用层的这个锁机制。

解决方案

解决此问题的步骤非常简单：

1. 移除应用程序中添加的自定义锁机制
2. 完全依赖PJProject 2.14.1版本内置的稳定性修复

经验总结

这个案例提供了几个有价值的经验教训：

1. 版本升级后的兼容性检查：当升级底层库版本时，需要重新评估之前添加的各种补丁和工作区间的必要性
2. 死锁问题分析方法：通过获取所有线程的完整堆栈信息，可以快速定位死锁发生的具体位置
3. 锁机制的使用原则：添加自定义锁时需要特别谨慎，确保在所有代码路径上都能正确释放

最终，通过移除不必要的应用层锁机制，视频通话的稳定性得到了显著提升，反复建立和挂断通话的操作也不再导致视频功能挂起。