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各有优缺点，实际项目中可根据具体需求选择使用哪个工具。两个工具的优缺点对比如下表。
在这里插入图片描述