前言

最近在調試 RT-Smart 上的用戶態 mq（消息隊列）時，遇到一個奇怪的問題，這個例程打印了一下獲取的時間，就可以正常的工作（超時退出），否則，就一直卡住（無法超時）

雖然沒有認真的閱讀用戶態 mq 的具體實現代碼，大概能了解到底層對接了 IPC 消息隊列，如果一直卡住，可能的原因是超時時間參數沒有正確傳遞下？

排查思路

當前未采用 qemu 調試，直接使用板子驗證，所以就手動增加了一些 LOG，用戶態應用與 內核態的應用，很快定位到是 內核代碼 softwarekernelcomponentslibccompilerscommonctime.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);

小結

這問題，如果粗心一點，可能會直接【放過】，比如加了 LOG 打印發現沒有問題，但是細節決定成敗，有些 BUG 可能出現的方式很奇特，這就是測試代碼需要有一定的覆蓋性，各個場景下都需要驗證，比如 Debug 版本、 Release 版本都測試一下，看看現象是否一致。

經過了解 int 溢出，也發現了一些基礎性的知識點，如 32位與64位 CPU 下， long long 類型都是 8字節，如果使用 long 類型定義 nsecond，在 32位平臺上，是 4字節，依舊是異常有問題

修復問題后，再次驗證，發現定時比較的準確了，偏差很小，比如 20秒，20000 個 tick,而不是 19001 個 tick

修復后，再次運行的效果，此時 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()