RT-Thread-RT-Smart 开发笔记：int 类型数值溢出造成的奇怪问题的分析与排查记录RT-Thread问答社区

RT-Smart 开发笔记：int 类型数值溢出造成的奇怪问题的分析与排查记录

发布于 2023-10-30 21:48:09 浏览：634 订阅该版

[tocm]

## 前言

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

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

## 排查思路

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

![微信图片_20231030204830.png](https://oss-club.rt-thread.org/uploads/20231030/60d67791e1c804231b19ada7f8755cd0.png)

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

![微信图片_20231030204807.png](https://oss-club.rt-thread.org/uploads/20231030/fe3d2c856a4cc1d2ffac3609c3d93a99.png)

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

![微信图片_20231030213223.png](https://oss-club.rt-thread.org/uploads/20231030/79e64c140b2298fe6943518967a344a0.png)

## 继续排查

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

![微信图片_20231030204839.png](https://oss-club.rt-thread.org/uploads/20231030/268b83c64513631b7457fca9d228a218.png)

![微信图片_20231030204854.png](https://oss-club.rt-thread.org/uploads/20231030/b8b24f34547d70593de21909d99e0caa.png)

![微信图片_20231030205049.png](https://oss-club.rt-thread.org/uploads/20231030/5abacafe60befc9aa05360cac542a8b3.png)

## 找到根源：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 是无符号的，所以把一个负值当成无符号数，就是一个比较大的数值

![2023-10-30_213708.png](https://oss-club.rt-thread.org/uploads/20231030/9d95de4c544cd4cf75797ec0b89bdf7d.png)

## 解决方法

- 第一种，把 `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);`

## 小结

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

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

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

![2023-10-30_204917.png](https://oss-club.rt-thread.org/uploads/20231030/965e61221a8d551a3b0007bc8f6eaff4.png.webp)

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

```c
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()
```