[Bug] Thread pause error in rt_thread_mdelay function

RT-Thread Version

5.2.0 commit 2f559906d6202c27142237ab4b1d893034a5b7c3

Hardware Type/Architectures

VEXPRESS_A9

Develop Toolchain

GCC

Describe the bug

Hi, i encountered an error in rt_thread_mdelay function.

Describe the bug

Incorrect message handling or mailbox state causes kernel stop in tcpip thread

Steps to reproduce

1.Build RT-Thread
2.Use the following command to start the kernel with QEMU:

qemu-system-arm \
    -M vexpress-a9 \
    -smp 2 \
    -m 4096M \
    -kernel /path/to/rt-thread/bsp/qemu-vexpress-a9/rtthread.bin \
    -drive if=sd,file=/path/to/rt-thread/bsp/qemu-vexpress-a9/sd.bin,format=raw \
    -nographic \
    -semihosting \

3.Use the functions and parameters provided in the ’Test case‘ section for testing

Source code location

/root/rtthread/rt-thread/components/net/lwip/port/sys_arch.c : sys_arch_mbox_fetch : 423 :

    /*When the waiting msg is generated by the application through signaling mechanisms,
    only by using interruptible mode can the program be made runnable again*/
    ret = rt_mb_recv_interruptible(*mbox, (rt_ubase_t *)msg, t); // 423
    if(ret != RT_EOK)
    {
        return SYS_ARCH_TIMEOUT;
    }

Test case

syz_thread_delay_ms()

long syz_thread_delay_ms(volatile int ms) {
    if (ms <= 0) {
        return -1;
    }
    rt_thread_mdelay((rt_int32_t)ms);
    return 0;
}

Backtrace upon hitting the bug

#executing syz_thread_delay_ms (0xb688)
2024/09/04 15:14:48 Syscall execution is ok
2024/09/04 15:14:51 qemu run inst merger err: execution timed out
2024/09/04 15:14:51 Received stop signal, requires feedback = true
2024/09/04 15:14:51 running diagnose
2024/09/04 15:14:51 VM-0 failed reading regs: dial tcp 127.0.0.1:24177: connect: connection refused
2024/09/04 15:14:51 VM-0 failed reading regs: dial tcp 127.0.0.1:24177: connect: connection refused
2024/09/04 15:14:51 Stack frames at BUG: unexpected stop:
2024/09/04 15:14:51 Level: 0: 1611238748, /root/kcov.c : __sanitizer_cov_trace_pc : 71 : 
2024/09/04 15:14:51 Level: 1: 1611495348, /root/rtthread/rt-thread/src/scheduler_up.c : rt_schedule : 238 : 
2024/09/04 15:14:51 Level: 2: 1611445488, /root/rtthread/rt-thread/src/ipc.c : _rt_mb_recv : 2912 : 
2024/09/04 15:14:51 Level: 3: 1611446256, /root/rtthread/rt-thread/src/ipc.c : rt_mb_recv_interruptible : 2974 : 
2024/09/04 15:14:51 Level: 4: 1611130960, /root/rtthread/rt-thread/components/net/lwip/port/sys_arch.c : sys_arch_mbox_fetch : 423 : 
2024/09/04 15:14:51 Level: 5: 1611104436, /root/rtthread/rt-thread/components/net/lwip/lwip-2.0.3/src/core/timeouts.c : sys_timeouts_mbox_fetch : 416 : 
2024/09/04 15:14:51 Level: 6: 1610890752, /root/rtthread/rt-thread/components/net/lwip/lwip-2.0.3/src/api/tcpip.c : tcpip_thread : 101 : 
2024/09/04 15:14:51 Level: 7: 1611546932, /root/rtthread/rt-thread/libcpu/arm/cortex-a/start_gcc.S : _thread_start : 628 : 

I would greatly appreciate it if you could kindly inform me of any mistakes in the previous issues.

Other additional context

No response

Reproduce the timeout with the provided QEMU VEXPRESS_A9 command and syz_thread_delay_ms test case. Start in components/net/lwip/port/sys_arch.c at sys_arch_mbox_fetch, then trace rt_mb_recv_interruptible and _rt_mb_recv in src/ipc.c against the tcpip_thread backtrace. Done means identifying the mailbox or scheduling failure and demonstrating that the kernel no longer stops under the reported case.