OpenSSL项目中lhash测试在多线程环境下的死锁问题分析

问题背景

在OpenSSL 3.4.1版本的测试过程中，开发人员发现lhash测试在某些较旧的Linux平台（如RHEL 6和SLES 11）上会出现CPU死循环的问题。这个问题特别出现在使用较老版本GCC编译器（4.3和4.4）的环境中，且与多线程测试相关。

问题现象

当运行lhash测试时，进程会进入CPU死循环状态。通过gdb调试工具获取的堆栈信息显示，程序卡在了pthread_rwlock_rdlock函数调用处。具体表现为：

1. 主线程尝试获取读锁
2. 调用链：CRYPTO_THREAD_read_lock → CRYPTO_atomic_load_int → hashtable_mt_free
3. 最终在ossl_synchronize_rcu函数中陷入循环

根本原因分析

经过深入调查，发现问题源于资源释放顺序的错误。具体来说：

1. 测试代码中先释放了原子工作锁(worker_lock)
2. 然后才尝试释放哈希表
3. 但是哈希表的释放操作本身需要使用这个已经被释放的锁

这种资源释放顺序的颠倒导致了死锁情况的发生。当哈希表尝试执行清理操作时，它需要获取已经被释放的锁，从而陷入无限等待状态。

解决方案

修复方案相对简单但有效：调整资源释放顺序。具体修改包括：

1. 先释放哈希表
2. 然后再释放工作锁

这样确保了在哈希表执行任何需要锁的操作时，锁资源仍然可用。

技术启示

这个案例给我们提供了几个重要的技术启示：

1. 资源生命周期管理：在多线程编程中，必须仔细考虑各种资源（特别是锁）的生命周期。确保在资源被依赖期间保持可用。

2. 测试覆盖：即使在CI环境中，某些边界条件可能无法被完全覆盖。这个案例中，线程检查工具(tsan)没有在CI中运行lhash测试，导致问题未被及时发现。

3. 平台兼容性：新功能（如多线程测试）在旧平台上的表现可能与预期不同，需要特别关注。

4. 调试工具限制：在某些旧平台上，先进的调试工具（如tsan）可能不可用，这时需要依赖传统工具（如gdb）进行问题诊断。

结论

OpenSSL项目中的这个案例展示了在多线程编程中资源管理的重要性。通过调整资源释放顺序，问题得到了解决。这也提醒开发者在实现多线程功能时，需要特别注意资源依赖关系和生命周期管理，特别是在跨平台开发场景下。

对于使用OpenSSL的开发者来说，这个修复确保了在旧Linux平台上的稳定性和可靠性，同时也为类似的多线程资源管理问题提供了参考解决方案。