背景
虽然才刚进入新环境，但是由于项目交付节点临近，领导主要让我分析、解决以前遗留的问题，保证软件的稳定性。
其中有一个问题现象是：片间通信进程（负责SOC和MCU交互的服务）偶现阻塞问题。经过短暂的分析，我怀疑是因为资源竞争导致的死锁问题。针对死锁问题，我认为有两种分析方式。
- 分析代码。分析各线程、进程之间的临界资源，在时序上，是否存在死锁的情况。若对代码架构比较熟悉，该方式应该是不错的方式。
- gdb调试。当时出现死锁时，肯定是存在了2个以上的线程在等待资源的释放，此时，我们可以通过
gdb -p查看对应进程、线程的堆栈信息，在wait哪一个临界资源。这样能够很快的定位到资源竞争的逻辑，但是需要问题复现。
因为是偶现问题，理论上应该采取方式一。但是因为此时我还有别的问题需要处理，于是选择了方式二：准备一个拷机环境，当问题复现时，直接用gdb调试分析，应该能节约很多时间。
计划是美好的，但是在搭建拷机环境中，遇到了gdb使用的问题，一直会提示Backtrace stopped: previous frame identical to this frame (corrupt stack?)错误，导致无法查看完整的堆栈信息，心想：若gdb无法使用，及时问题复现，也不能定位到阻塞点，应该优先解决该问题。
最终经过查阅资料以及咨询模组供应商，最终解决了。这个过程包括分析的思路，以及和供应商之间的battle。希望能给遇到的朋友一些建议、帮助
标签：identical,问题,Backtrace,frame,stripped,gdb,so,32,2.22 From： https://blog.csdn.net/xieyihua1994/article/details/137422382