QNX常用调试方法
1. top
查询系统状态最常用的工具是top,它可以显示系统资源的使用情况。我们最关心的通常是系统可用内存和CPU使用率。如果CPU使用率过高可能是因为某些应用存在bug,重点关注下面显示的占用CPU资源最多的几个线程。如果可用内存太少,可能某些应用存在内存泄漏情况。但top工具无法显示占用内存最多的应用,我们可以使用另外一个工具hogs。
2. hogs
hogs工具和top类似,默认也是按照CPU使用情况对进程进行排序。但可以指定-S m参数使其按内存使用情况排序,这样就能揪出消耗内存最多的几个进程了。知道了哪个进程消耗内存最多,我们还是无法判断它是否存在内存泄漏,因为无法判断占用内存多的是哪部分。如果能看到该进程的Heap越来越大,才可以确认它存在内存泄漏。
ages/20230724024159.png?origin_url=file%3A%2F%2F%2F%2Ftmp%2Fwps-dgliu%2Fksohtml%2FwpsVEMXl1.jpg&pos_id=img-vCzAtoL1-1701587889811)
3. pidin
锁定了嫌疑进程后就可以对其进行详细信息查询了。在QNX上查询进程信息最基本的工具是pidin,它类似Linux上的ps命令。这两个工具在QNX上都是基于proc文件系统实现的,但pidin比ps功能要更强大。pidin的命令行参数支持六十多种格式码,每个格式码代表一种信息,可任意组合。估计该工具的作者怕使用者记不住这么多参数,又提供了一些shorthand,就是一些预设的格式码组合。常用的有:arg用于显示进程参数,fds用于显示进程打开的连接和文件,user用于显示进程的用户信息等。pidin默认显示所有进程的信息,如只想查询指定进程信息,可用-p参数指定进程名或pid。
性能分析工具
有时调试进程不一定是因为应用存在逻辑bug,也可能是应用性能无法满足需求,例如处理某个函数耗时过长,或CPU占用率过高。这时就需要对应用进行性能分析,从而找到优化方案。这时可以考虑使用tracelogger。
1. tracelogger
如果想知道QNX内核在一段时间内都干了什么,最常用的工具就是tracelogger了。该工具可以将内核事件记录到.kev文件中进行分析。kev表示kernel event,包括系统调用、调度行为、中断处理以及进程和线程的创建、销毁和状态改变等等。这些事件都来自procnto*-instr,开始记录后内核会将事件信息保存到内存buffer中,每个buffer的大小为16KB,buffer数量由tracelogger设置,默认32个。记录完成后tracelogger会将buffer中的数据转储到指定的kev文件中。
手动启动tracelogger的方式比较灵活,可用-n参数指定buffer个数,当存满这么多buffer后就停止记录,如:
tracelogger -f /var/log.kev -n 12
也可以用-s指定时间,单位是秒,记录这么长时间后就停止,如:
tracelogger -f /var/log.kev -s 3
也可以用-r指定循环模式,记录过程buffer中的数据会循环覆盖,不会写入kev文件,直到用户按Ctrl+C才停止,然后将buffer中的数据写入文件。
tracelogger -f /var/log.kev -r -b 5
得到kev文件后可用traceprinter工具进行解析,也可以用Momentics IDE进行解析。
traceprinter只是按顺序将内核事件解析成文本格式,不方便过滤分析,但这个工具是SDK自带的,无需额外购买license。解析的结果如下图所示:
Momentics IDE提供图形化解析工具,可过滤感兴趣的进程和事件,功能强大,使用方便,但需要购买license。解析结果如下图所示
进程监测工具
即使实验室中充分测试过的软件也无法保证在真实工况下不崩溃,毕竟物理世界有太多意想不到的情况。我们能做的只有在应用异常退出时,尽量自动恢复其功能。可以说进程监控工具是保障运行时功能的最后一道防线。QNX提供了两个工具可以监控进程,并在其异常退出时重启该进程,即SLM和HAM。下面简单介绍一下这两个工具。
1. SLM
SLM是System Launch and Monitor的缩写,用于启动和监控必须按指定顺序启动的复杂应用。SLM使用XML文件作为配置文件,将待启动的应用在xml文件中配置好,启动slm时指定该xml文件即可,如:
/bin/slm -V /slm/service_apps.xml
以下面的代码片段为例,简单介绍下slm配置文件的用法。每个进程都是一个component,该文件定义了两个component,分别是chime_service和ic_chime。type指定进程的安全类型,user指定进程的用户和组,command指定启动命令行,waitfor等待路径名出现,priority指定优先级和调度策略,partition指定aps分区,depend指定依赖的component,stdout和stderr重定向标准输出和标准错误。
<SLM:component name="chime_service">
<SLM:type>chime_service_t</SLM:type>
<SLM:user>chime:iceoryx</SLM:user>
<SLM:command launch="pathname">/bin/chime_service</SLM:command>
<SLM:waitfor wait="pathname">/dev/chime_service</SLM:waitfor>
<SLM:priority>10r</SLM:priority>
<SLM:partition>aps_ic</SLM:partition>
</SLM:component>
<SLM:component name="ic_chime">
<SLM:depend>chime_service</SLM:depend>
<SLM:type>ic_apps_t</SLM:type>
<SLM:user>ic_apps:iceoryx</SLM:user>
<SLM:command launch="pathname">/usr/bin/ic_chime</SLM:command>
<SLM:priority>10r</SLM:priority>
<SLM:partition>aps_ic</SLM:partition>
<SLM:stdout>/dev/slog2/stdout</SLM:stdout>
<SLM:stderr iomode="a">/dev/slog2/stderr</SLM:stderr>
</SLM:component>
这段配置的意思是ic_chime依赖chime_service,slm会先启动chime_service,等待/dev/chime_service设备出现后再启动ic_chime。如果chime_service异常退出了,slm会先把ic_chime杀死,然后重启chime_service,再重启ic_chime。
SLM的优点是可以处理进程间的依赖关系,但在进程退出时它只能重新启动该进程,无法执行其他动作。有时关键进程退出后,由于依赖它的进程太多了,依次杀掉所有进程后再重启一遍,还不如直接重启系统方便。
2. HAM
HAM是High Availability Manager的缩写,它能提供一种监控进程的机制。HAM的结构主要包括三部分:实体、条件、动作。每个被监控的进程都是一个实体,其下可注册多个条件,每个条件下可注册多个动作。一旦被监控的进程满足预设的条件,即可执行相应的动作。所有注册到HAM的实体都可以在/proc/ham目录下看到其状态。
下面的代码片段的功能就是将进程本身注册到HAM。首先用ham_attach_self()注册一个实体,名为”sys_monitor”,HAM监控的pid即为该进程本身的pid;然后用ham_condition()在该实体下注册一个条件,类型为CONDDEATH;最后在这个条件下注册一个restart动作。当该进程死掉时HAM就会执行预设的动作,调用/bin/sys_monitor命令行。新起来的进程又会执行同样的代码将新pid再次注册到HAM。
static int32_t attach_self_to_ham()
{
ham_entity_t *ehdl;
ham_condition_t *chdl;
ham_action_t *ahdl;
/* attach to HAM */
ehdl = ham_attach_self("sys_monitor", 0, 0, 0, 0);
/* register a DEATH event condition */
chdl = ham_condition(ehdl, CONDDEATH, "death", HREARMAFTERRESTART);
/* tell HAM to restart sys_monitor in case it crashes */
ahdl = ham_action_restart(chdl, "restart", "/bin/sys_monitor", HREARMAFTERRESTART);
return 0;
}
HAM虽然可以自定义条件和动作,但使用HAM的应用都要添加相应代码,太过麻烦,而且有些系统工具我们没有源码无法添加新功能。最重要的是HAM不支持指定安全类型。在启用了secpol的系统中,启动应用时通常要用on命令指定security type和user等信息。但如果ham_attach()或ham_action_restart()里的命令行也用on来启动,则ham监控的就是on的pid,而不是要启动的应用的pid。如果应用代码中调用了daemon()函数,那on就会退出。ham则会认为实体退出了从而再次执行该命令行。导致应用被多次误启动。
3. 小结
SLM、HAM各有优缺点,实际项目中可根据具体需求选择使用哪个工具。两个工具的优缺点对比如下表。
其它IDE的调试方法
http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.ide.userguide/topic/analyze_performance.html