[Bug] Mutex initialization error in _heap_lock_init function

RT-Thread Version

5.2.0 commit 2f559906d6202c27142237ab4b1d893034a5b7c3

Hardware Type/Architectures

VEXPRESS_A9

Develop Toolchain

GCC

Describe the bug

Mutex initialization failure due to invalid lock state or resource exhaustion

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/src/kservice.c : 534

rt_inline void _heap_lock_init(void)
{
#if defined(RT_USING_HEAP_ISR)
    rt_spin_lock_init(&_heap_spinlock);
#elif defined(RT_USING_MUTEX)
    rt_mutex_init(&_lock, "heap", RT_IPC_FLAG_PRIO);  // 534
#endif
}

Test case

syz_system_heap_init ()

void syz_system_heap_init() {
    void *begin_addr = malloc(1024 * 1024);
    void *end_addr = begin_addr + 1024 * 1024;
    rt_system_heap_init(begin_addr, end_addr);
}

Backtrace upon hitting the bug

#executing syz_system_heap_init ()
2024/09/04 07:57:59 Syscall execution is ok
(obj != object) assertion failed at function:rt_object_init, line number:374 
backtrace:
2024/09/04 07:58:08 qemu run inst merger err: execution timed out
2024/09/04 07:58:08 Received stop signal, requires feedback = true
2024/09/04 07:58:08 running diagnose
2024/09/04 07:58:08 VM-0 failed reading regs: dial tcp 127.0.0.1:54650: connect: connection refused
2024/09/04 07:58:08 VM-0 failed reading regs: dial tcp 127.0.0.1:54650: connect: connection refused
2024/09/04 07:58:08 Stack frames at BUG: unexpected stop:
2024/09/04 07:58:08 Level: 0: 1611238884, /root/kcov.c : write_comp_data : 111 : 
2024/09/04 07:58:08 Level: 1: 1611239238, /root/kcov.c : __sanitizer_cov_trace_const_cmp1 : 167 : 
2024/09/04 07:58:08 Level: 2: 1611470092, /root/rtthread/rt-thread/src/kservice.c : rt_assert_handler : 1022 : 
2024/09/04 07:58:08 Level: 3: 1611489164, /root/rtthread/rt-thread/src/object.c : rt_object_init : 374 : 
2024/09/04 07:58:08 Level: 4: 1611430224, p[ : rt_mutex_init : 1014 : 
2024/09/04 07:58:08 Level: 5: 1611468224, /root/rtthread/rt-thread/src/kservice.c : _heap_lock_init : 534 : 
2024/09/04 07:58:08 Level: 6: 1611468768, /root/rtthread/rt-thread/src/kservice.c : _rt_system_heap_init : 656 : 
2024/09/04 07:58:08 Level: 7: 1611468816, /root/rtthread/rt-thread/src/kservice.c : rt_system_heap_init : 668 : 
2024/09/04 07:58:08 Level: 8: 1611214072, /root/rtthread/rt-thread/bsp/qemu-vexpress-a9/applications/common_freertos.h : syz_system_heap_init : 223 :

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

Other additional context

No response

Start with _heap_lock_init and rt_system_heap_init in src/kservice.c, then inspect rt_mutex_init and rt_object_init in src/object.c using the supplied backtrace. Reproduce the assertion with syz_system_heap_init on the QEMU vexpress-a9 target and determine why initialization reaches the existing object. Done means the reported test no longer triggers the assertion or timeout, with the relevant behavior covered by a regression test if the project provides one.