前言

• 最近在调试 RT-Smart 上的用户态 mq（消息队列）时，遇到一个奇怪的问题，这个例程打印了一下获取的时间，就可以正常的工作（超时退出），否则，就一直卡住（无法超时）

• 虽然没有认真的阅读用户态 mq 的具体实现代码，大概能了解到底层对接了 IPC 消息队列，如果一直卡住，可能的原因是超时时间参数没有正确传递下？

排查思路

• 当前未采用 qemu 调试，直接使用板子验证，所以就手动增加了一些 LOG，用户态应用与 内核态的应用，很快定位到是 内核代码 software\kernel\components\libc\compilers\common\ctime.c 中的函数 rt_timespec_to_tick 返回值异常导致的

• 开启log 打印一下时间，就可以【正常】退出

• 不开启 log，发现卡住了，也就是 ipc 一直没有超时

继续排查

• 发现 tick 计算的有问题，异常的 tick，也就是 IPC timeout 非常大

• 找到根源：int 型乘法计算溢出

tick = second * RT_TICK_PER_SECOND + nsecond * RT_TICK_PER_SECOND / NANOSECOND_PER_SECOND;，这里 nsecond 定义为 int 类型，int 是 32位，所以当 nsecond 较大时，再
乘上 RT_TICK_PER_SECOND, 也就是 1000，由于32位有符号整数溢出，变为了【负值】。而此时 second 比较小，造成 tick 为一个 负值，但是 timeout 是无符号的，所以把一个负值当成无符号数，就是一个比较大的数值

解决方法

• 第一种，把 nsecond 定义为 int64_t 类型，也就是 long long 类型，这样计算时，会按照 64位计算，不会溢出

• 第二种：把 tick = second * RT_TICK_PER_SECOND + nsecond * RT_TICK_PER_SECOND / NANOSECOND_PER_SECOND; 改为 tick = second * RT_TICK_PER_SECOND + nsecond / (NANOSECOND_PER_SECOND / RT_TICK_PER_SECOND);

• 修复后，再次运行的效果，此时 tick = 19994，与 20秒比较匹配

msh /kernel>./mq_test
msh /kernel>31111111111111111111111111111
msg_queue is 3
main : enter
sys_mq_timedreceive : 5974  1514764824-963161303
tp : 1676378 - 1514764804
tm_spec : 1676378 - 1514764824
rt_timespec_to_tick : line - 730, second : 19, nsecond : 994459929
rt_timespec_to_tick : tick = 19994
mq_timedreceive : tick = 19994
mq_receive()

小结

• 这问题，如果粗心一点，可能会直接【放过】，比如加了 LOG 打印发现没有问题，但是细节决定成败，有些 BUG 可能出现的方式很奇特，这就是测试代码需要有一定的覆盖性，各个场景下都需要验证，比如 Debug 版本、 Release 版本都测试一下，看看现象是否一致。

• 经过了解 int 溢出，也发现了一些基础性的知识点，如 32位与64位 CPU 下， long long 类型都是 8字节，如果使用 long 类型定义 nsecond，在 32位平台上，是 4字节，依旧是异常有问题

• 修复问题后，再次验证，发现定时比较的准确了，偏差很小，比如 20秒，20000 个 tick,而不是 19001 个 tick