自媒体135网站,网站百度建设,企业展厅设计公司推荐,湖州建设局招投标网站目录
1、初始问题描述
2、使用Process Explorer工具查看到处理音视频业务的rtcmpdll.dll模块没有加载起来
3、使用Dependency Walker工具查看到rtcmpdll.dll依赖的库有问题
4、更新库之后Debug程序启动时就发生异常#xff0c;程序闪退
5、VS调试时看不到有效的函数调用堆…目录
1、初始问题描述
2、使用Process Explorer工具查看到处理音视频业务的rtcmpdll.dll模块没有加载起来
3、使用Dependency Walker工具查看到rtcmpdll.dll依赖的库有问题
4、更新库之后Debug程序启动时就发生异常程序闪退
5、VS调试时看不到有效的函数调用堆栈使用Windbg启动目标程序去查看异常时的函数调用堆栈
6、引入rtcmediacontrol音频处理插件的原因
7、分析引发WebRTC开源库内部调用C运行时函数abort强制结束进程的原因
7.1、初步分析
7.2、查看WebRTC开源库对应的源码分析程序的走向
7.3、找到触发abort终止进程操作的最终原因
8、最后 VC常用功能开发汇总专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/124272585C软件异常排查从入门到精通系列教程专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/125529931 最近在项目中遇到了一个比较典型的问题由于调用WebRTC开源库的RegisterAudioCallBack接口的线程与创建ADM音频设备管理对象的线程不是同一线程触发了WebRTC内部在Debug下的Check校验失败触发了WebRTC内部调用abort接口强行将程序进程终止导致程序发生闪退。本文讲解一下这一问题的完整排查过程。
1、初始问题描述 为了排查会议中的相关问题在Visual Studio中对代码进行Debug下的调试发现视频窗口无法显示对应与会终端的视频与会终端的摄像头是开着的测试同事电脑上安装的Release版本软件终端入会后是可以其他与会软件终端的视频图像的。于是要排查一下我这边Debug版本软件为啥不显示其他与会终端的视频图像。
2、使用Process Explorer工具查看到处理音视频业务的rtcmpdll.dll模块没有加载起来 以前遇到过类似的问题处理音视频业务的组件库rtcmpdll.dll是动态启动的是不是这个库没有启动起来 rtcmpdll.dll库是在初始化组件的模块时底层调用LoadLibrary或者LoadLibraryEx动态启动的。于是启动Process Explorer工具找到Debug版本的程序进程查看进程启动的dll库列表、 rtcmpdll.dll确实没有启动起来没有加载到进程空间中。
3、使用Dependency Walker工具查看到rtcmpdll.dll依赖的库有问题 rtcmpdll.dll之所以没有启动起来基本是因为rtcmpdll.dll依赖的底层库有问题一般有两种情况 1依赖的dll库在系统中找不到。这个可能是打包安装程序时没有将dll库打包到安装包中导致的。 2调用了被依赖的库中的接口但在当前系统中找到的该dll库中找不到接口或者接口的参数不一致。这一般是主dll库与被依赖的dll库版本不一致导致的。 可以使用Dependency Walker工具看一下。启动该工具将rtcmpdll.dll库拖进工具中发现其调用了其依赖的rtcmediacontrol.dll中的RegisterRtcLogCallBack接口 但在rtcmediacontrol.dll库中找不到该接口那应该是rtcmpdll.dll和rtcmediacontrol.dll库版本不一致导致的。
4、更新库之后Debug程序启动时就发生异常程序闪退 于是和rtcmediacontrol库的开发同事确认了一下他们最近确实发布了新版本的rtcmediacontrol库于是取来最新Debug版本的rtcmediacontrol库放到Debug路径下重新启动VS调试结果一启动就报错了 打开Call stack函数调用堆栈页面也看不到有效的函数调用堆栈 以前遇到过调用IsBadReadPtr导致VS报错的于是点击继续调试按钮结果还是报错查看报错时的函数调用堆栈也看不到具体是哪个函数触发的也看不到具体的函数调用堆栈。 对于在VS中调试启动程序报错时看不到有效的函数调用堆栈的问题我们遇到很多次了可以尝试使用Windbg启动Debug版本的exe主程序Windbg能感知到程序启动时发生异常并中断下来然后就可以看到发生异常时的函数调用堆栈。 这个问题有些奇怪只有Debug版本程序在启动后会闪退Release版本的程序是没有问题的测试同事那边安装的最新Release版本运行是没问题的启动时不会报错软件的日常开发和维护主要是在IDE Debug下进行调试的而Debug下程序启动后有闪退直接导致程序没法进行Debug调试所以这个问题必须要排查解决我们还需要搞清楚为啥Debug下有闪退、Release下没问题要排查软件中可能存在的隐患 因为Debug和Release下的不同代码控制或内存差异可能会出现Debug和Release下运行的不同现象。比如Debug下运行没问题Release下运行有异常这在日常项目中比较常见。而本例中遇到的Release下运行正常、Debug下闪退的问题是比较少见的越是少见的问题我们越要研究要高清楚为什么会出现这样的问题 5、VS调试时看不到有效的函数调用堆栈使用Windbg启动目标程序去查看异常时的函数调用堆栈 于是启动Windbg打开Debug版本的exe主程序即通过Windbg启动目标程序一上来就遇到了调用IsbadReadPtr引发的异常中断 输入g命令跳过去即可连续遇到三次这样的中断所以连续g了三次。 结果又遇到了调用DebugBreak引发的中断 DebugBreak是系统API函数调用该函数是为了让当前正在调试的调试器中断下来比如正在调试的IDE、正在调试的Windbg等。调试器中断下来后就可以查看此时的函数调用堆栈就知道当前发生什么问题了。 于是在DebugBreak触发Windbg中断下来时输入kn命令查看此时的函数调找来了相关模块的pdb文件发现是rtcmediacontrol库调用了WebRTC开源库中的RegisterAudioCallBack接口触发的。
6、引入rtcmediacontrol音频处理插件的原因 我们在软件中要实现会议中扬声器的静音最好的做法是在收到平台服务器给过来的音频数据不解码播放就可以了。但试了WebRTC的很多接口不是达不到效果就是多次频繁操作静音会引发崩溃。 如果按照理想的做法在收到远端传过来的音频数据不解码播放需要去修改WebRTC内部关于混音的代码但这回牵涉到很多代码比较复杂不好修改。所以中途引入了一个规避的方法让上层去实现扬声器静音不再依赖WebRTC库内部的实现。 具体的做法是让UI层通过COM组件技术去将当前软件进程的声音关闭掉这样就听不到会议中的声音了。关闭目标进程的声音的相关代码可以参照下面的文章
https://blog.csdn.net/chenlycly/article/details/128966612http://VC打开或关闭目标进程的声音附源码但这有个问题整个进程的声音都没有了这样进程中的其他声音都不播放了比如IM子系统中收到消息的提示音都听不到了。所以这种做法也不是很合适。 后来为了彻底解决这个扬声器静音的问题引入了rtcmediacontrol库把这个库作为WebRTC库引入的音频处理插件在这个库去控制是否去解码播放音频数据。
7、分析引发WebRTC开源库内部调用C运行时函数abort强制结束进程的原因
7.1、初步分析 WebRTC库内部调用DebugBreak让调试器中断下来紧接着应该就是abort将进程终止掉如下 在Windbg中输入g命令将DebugBreak引发的中断跳过去紧接着就弹出了abort终止调试的提示框。 对于WebRTC内部先调用DebugBreak后调用abort将进程强行终止掉的场景以前我们遇到过当时使用malloc去申请一段内存结果malloc返回NULL内存申请失败然后就触发了强行终止进程的操作。估计是WebRTC开源库认为内存申请失败会导致相关数据没法处理相关业务没法执行下去进程没有活下去的必要了所以就强行将进程终止掉。 在调用abort之前调用DebugBreak函数就是让调试器感知一下可以查看函数调用堆栈看看当前执行了什么操作。 从函数调用堆栈看调用的webrtc::AudioDeviceBuffer::RegisterAudioCallBack函数怎么位于rtcmediacontrol.dll模块中呢这是因为rtcmediacontrol.dll库引用了WebRTC开源库引用的静态库不是动态库所以还归属于rtcmediacontrol.dll库。
7.2、查看WebRTC开源库对应的源码分析程序的走向 根据调用Windbg中显示的函数调用堆栈中的函数AudioDeviceBuffer::RegisterAudioCallBack及行号到WebRTC开源代码中找到对应的代码行如下所示 对应的代码行为82行但82行对应的是一行打印日志的代码应该不是这行代码引起的。函数调用堆栈中显示的行号是当前函数调用被调用函数的返回地址那一行所以应该是81行代码引发DebugBreak调用的。 81行代码是一个叫做RTC_DCHECK_RUN_ON的宏根据名称大概猜测出来当前这个宏是用来做Debug下Check的。所以这个Check应该是Debug下的CheckRelease下不执行这个Check是不是这个Check内部在检测到条件不满足时触发了DebugBreak和abort调用了呢这个Debug Check是不是导致Debug下有闪退、Release下没有闪退的原因呢经后面研究得知确实是这样的正是这个Debug Check导致Debug和Release下不同表现的。 于是Go到RTC_DCHECK_RUN_ON宏的内部实现代码 果然是不满足条件时就会调用rtc_FatalMessage接口rtc_FatalMessage接口会调用FatalLog接口这个FatalLog接口中会先调用DebugBreak、后调用abort强制将进程关闭掉。 这个地方有一个控制变量RTC_DCHECK_IS_ON宏应该是通过这个宏去感知当前是不是Debug版本的GO到RTC_DCHECK_IS_ON的定义处 果然是和NDEBUG相关的如果当前是Debug版本RTC_DCHECK_IS_ON宏就被定义为1如果当前是Release版本则宏会被定义为0。
7.3、找到触发abort终止进程操作的最终原因 GO到RTC_DCHECK_RUN_ON内部看看为啥条件不满足Check。内部调用了RTC_DCHECK宏该宏中的判断条件是(x)-IsCurrent()如下 在rtcmediacontrol库中从WebRTC的音频设备管理类类继承出一个子类在这个子类中对音频进行控制。上述判断条件是(x)-IsCurrent()估计是判断调用RegisterAudioCallBack接口时所在线程是不是和创建ADM音频设管理类的线程是不是同一个线程WebRTC内部要求这两个线程必须在同一个线程中。 创建ADM音频设备管理类对象和对RegisterAudioCallBack接口的调用都是由组件层去做的组件的同事查看代码得知这两个操作确实不在同一个线程中执行的一个是在singals线程一个是在Worker线程中所以不在一个线程中所以调用RegisterAudioCallBack接口时触发Check失败导致调用了rtc_FatalMessage接口进而调用了DebugBreak和abort接口所以导致程序启动时的闪退。
8、最后 本问题中程序启动时会去调用RegisterAudioCallBack接口会触发RTC_DCHECK校验不通过然后触发DebugBreak和abort的调用导致Debug版本程序闪退。但这个Check只在Debug下设置Release下不会生效所以Release下不会闪退。 之前音视频编解码组在对rtcmediacontrol自测时主要进行的是Release下的自测。然后音视频编解码组将库发到组件那边组件那边进行的也是Release下的联调然后编译将新版本发布到我们产品流上产品流上编译的Release安装包在测试机器上安装后运行也没问题所以Debug下的闪退一直没暴露出来。直到我们产品这边需要更新底层库搭建最新的Debug运行环境时才暴露出来。
