昇腾学院 | 案例分享 DestroyGraph阻塞问题

问题现象描述

硬件配置：Atlas 500

问题现象：客户的业务代码在进行DestryGraph时，程序被阻塞，不能正常退出。

关键过程、根本原因分析

关键过程：

1.排查DestroyGraph阻塞的一般原因：引擎线程阻塞，无法退出；内存资源未能全部释放。

2.使用gdb查看当前业务进程的线程信息，如下图所示：

3.红框中的信息表明：引擎号为966的face_register线程还在挂起，未能退出。初步定位出原因为引擎线程无法关闭。

4.检视face_register.cpp代码，发现业务代码中使用了死循环来监听网络信息，导致线程一直无法退出。如下图所示：

根本原因分析：

1、face_register引擎线程中存在死循环，导致线程无法退出。从而阻塞后续析构函数的执行，内存资源无法释放，最终DestroyGraph阻塞，无法正常退出。

结论、解决方案及效果

结论：

线程中存在死循环，导致线程无法退出。DestroyGraph便一直等待线程退出，导致程序阻塞。

解决方案：

•  新开辟线程，以执行监听业务，从而去除死循环。引擎线程即可正常退出。DestroyGraph正常执行。经验总结、预防措施和规范建议

•  在engine的process函数中，尽量不要写死循环的程序，否则会导致DestryGraph函数执行失败。

• 若要写有死循环的程序，应当采用新开辟线程的方式，在新开的线程中执行死循环。最后在engine的析构函数中通过信号量来关闭这个死循环的线程。