前言
-
最近在调试 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
