[Bug] assertion failed in function rt_completion_wait_flags
RT-Thread Version
master commit accd616
Hardware Type/Architectures
riscv64 fpga
Develop Toolchain
GCC
Describe the bug
When running the RT-Thread Smart version and using an SPI TF card as a storage medium, in the SPI driver, synchronization of the send completion is implemented through the rt_completion_wait and rt_completion_done APIs. However, when running the hello example from userapps(https://github.com/RT-Thread/userapps/tree/main/apps/hello) in the ash shell, the following error occurs:
/ # hello hello world! (result != RT_EOK) assertion failed at function:rt_completion_wait_flags, line number:139
Here is the source code when the error occurs:
```
else
{
/* no changes, waiting failed */
result = thread->error;
result = result > 0 ? -result : result;
RT_ASSERT(result != RT_EOK);
}
Other additional context
When the error occurs, checking the system status, shows rt_thread_ready_priority_group = 0 and rt_scheduler_lock_nest =0. And now the status of idle thread is 0x7, the idle task is suspended. Here is the stack trace when the idle task is suspended:
#0 _thread_set_suspend_state (thread=thread@entry=0xffffffc0002adf58 <idle_thread>, suspend_flag=suspend_flag@entry=2)
#1 0xffffffc0002718a6 in rt_thread_suspend_to_list (thread=thread@entry=0xffffffc0002adf58 <idle_thread>, susp_list=susp_list@entry=0xffffffc000295328 <fdlock+40>,
ipc_flags=<optimized out>, suspend_flag=suspend_flag@entry=2)
#2 0xffffffc00026a06c in _rt_mutex_take (mutex=mutex@entry=0xffffffc000295300 <fdlock>, timeout=timeout@entry=-1, suspend_flag=suspend_flag@entry=2)
#3 0xffffffc00026a318 in rt_mutex_take (mutex=mutex@entry=0xffffffc000295300 <fdlock>, time=time@entry=-1)
#4 0xffffffc00020f434 in dfs_file_lock () at /home/turtle/zhangjing/bak/rt-thread/components/dfs/dfs_v2/src/dfs.c:158
#5 0xffffffc000213fb2 in on_varea_close (varea=0xffffffc0003067c8)
#6 0xffffffc000248128 in _varea_uninstall_locked (varea=varea@entry=0xffffffc0003067c8)
#7 0xffffffc0002474ee in rt_aspace_detach (aspace=aspace@entry=0xffffffc000305d88)
#8 0xffffffc000247574 in rt_aspace_delete (aspace=0xffffffc000305d88)
#9 0xffffffc00021e91c in arch_user_space_free (lwp=lwp@entry=0xffffffc0002f18c8)
#10 0xffffffc000239f62 in lwp_unmap_user_space (lwp=lwp@entry=0xffffffc0002f18c8)
#11 0xffffffc00022b2a0 in lwp_free (lwp=lwp@entry=0xffffffc0002f18c8)
#12 0xffffffc00022b97e in lwp_ref_dec (lwp=lwp@entry=0xffffffc0002f18c8)
#13 0xffffffc00021f63e in lwp_cleanup (tid=tid@entry=0xffffffc0002f3998)
#14 0xffffffc000268790 in rt_defunct_execute ()
#15 0xffffffc000268806 in idle_thread_entry (parameter=0x0)
#16 0xffffffc0002001a2 in _rt_thread_entry ()
https://github.com/RT-Thread/rt-thread/pull/9367 很大可能是这里的问题引起的
#9367 很大可能是这里的问题引起的
验证了下,merge pr9367后可以解决该问题。