目录搜索引擎网站,上海松江区做网站公司,所有免费的网站有哪些,箱包网站设计前言 最近在调试 RT-Smart 上的用户态 mq#xff08;消息队列#xff09;时#xff0c;遇到一个奇怪的问题#xff0c;这个例程打印了一下获取的时间#xff0c;就可以正常的工作#xff08;超时退出#xff09;#xff0c;否则#xff0c;就一直卡住#xff08;无法…前言 最近在调试 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 /kernel31111111111111111111111111111
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
