【sem bug】在aarch64平台，压测过程中发现sem死机概率高？

发布于 2022-02-14 11:44:18 浏览：993 订阅该版

[tocm]

# 平台
`qemu-virt64-aarch64`

# git版本
`5178e7ec0`

# 复现步骤
1. 修改`bsp/qemu-virt64-aarch64 menuconfig`为smp
2. `scons`
3. `./qemu.sh`
4. 起来的qemu命令行输入_thread_sample运行测试代码

# 测试代码
```c
/*
 * Copyright (c) 2006-2021, RT-Thread Development Team
 *
 * SPDX-License-Identifier: Apache-2.0
 *
 * Change Logs:
 * Date           Author       Notes
 * 2017-5-30      Bernard      the first version
 */

#include <rtthread.h>
#include <rthw.h>

int main(int argc, char** argv)
{
    rt_kprintf("Hi, this is RT-Thread!!\n");

return 0;
}

static struct rt_semaphore s_sem;
static void _cpu_bind_thread_entry(void *parameter)
{
    int count = 0;

while (1)
    {        
        count++;
        rt_kprintf("[%d]running [%d]\r\n", rt_hw_cpu_id(), count);
#if 1
        rt_sem_take(&s_sem, RT_WAITING_FOREVER);
        rt_sem_release(&s_sem);
#else
{
        void *p = RT_NULL;
        p = rt_malloc(1024);
        if(RT_NULL == p)
        {
            rt_kprintf("malloc fail \r\n");
            break;
        }
        rt_free(p);
}
#endif
    }
}
static rt_thread_t s_ThteadId = RT_NULL;
#define THREAD_PRIORITY 15
#define THREAD_STACK_SIZE 2048
#define THREAD_TIMESLICE 5

static void _thread_sample(void)
{
    rt_ubase_t i;
    char ThreadName[RT_NAME_MAX];

rt_sem_init(&s_sem, "test", 1, RT_IPC_FLAG_PRIO);

for (i = 0; i <RT_CPUS_NR; i++)
    {
        s_ThteadId = RT_NULL;
        rt_sprintf(ThreadName, "cpu%d-Thread", i);
        /* 创建线程 1，名称是 thread1，入口是 thread1_entry*/
        s_ThteadId = rt_thread_create(ThreadName,
                                        _cpu_bind_thread_entry, RT_NULL,
                                        THREAD_STACK_SIZE,
                                        THREAD_PRIORITY, THREAD_TIMESLICE);

rt_thread_control(s_ThteadId, RT_THREAD_CTRL_BIND_CPU, (void *)i);
        /* 如果获得线程控制块，启动这个线程 */
        if (s_ThteadId != RT_NULL)
            rt_thread_startup(s_ThteadId);
        else    
            rt_kprintf("create cpu-bind-thread fail\r\n");
    }

return;
}
/* 导出到 msh 命令列表中 */
MSH_CMD_EXPORT(_thread_sample, thread sample);
```
# 运行日志
```
xhwang@xhwang-VirtualBox:~/work/rt-thread/bsp/qemu-virt64-aarch64 [master]$ ./qemu.sh 
heap: [0x4006741c - 0x4016741c]

\ | /
- RT -     Thread Operating System
 / | \     4.1.0 build Feb 14 2022 11:05:29
 2006 - 2022 Copyright by RT-Thread team
call cpu 1 on success
msh />Hi, this is RT-Thread!!

msh />_
_thread_sample
msh />_thread_sample
[0]running [1]
[0]running [2]
[0]running [3]
[0]running [4]
[0]running [5]
[0]running [6]
[0]running [7]
[0]running [8]
[0]running [9]
[0]running [10]
[0]running [11]
[0]running [12]
[0]running [13]
[0]running [14]
[0]running [15]
[0]running [16]
[0]running [17]
[0]running [18]
[0]running [19]
[0]running [20]
[0]running [21]
[0]running [22]
[0]running [23]
[0]running [24]
[0]running [25]
[0]running [26]
[0]running [27]
[0]running [28]
[0]running [29]
[0]running [30]
[0]running [31]
[0]running [32]
[0]running [33]
[0]running [34]
[0]running [35]
[0]running [36]
[0]running [37]
[0]running [38]
[0]running [39]
[0]running [40]
[0]running [41]
[0]running [42]
[0]running [43]
[0]running [44]
[0]running [45]
[0]running [46]
[0]running [47]
[0]running [48]
[[1]running [1]
[1]running [2]
[1]running [3]
[1]running [4]
[1]running [5]
[1]running [6]
[1]running [7]
[1]running [8]
[1]running [9]
[1]running [10]
[1]running [11]
[1]running [12]
[1]running [13]
[1]running [14]
[1]running [15]
[1]running [16]
[1]running [17]
[1]running [18]
[1]running [19]
[1]running [20]
[1]running [21]
[1]running [22]
error exception:
Execption:
X00:0x0000000000000400 X01:0x0000000077000601 X02:0x0000000076e00601 X03:0x00000000400435f0
X04:0x0000000000000000 X05:0x0000000000000000 X06:0x0000000000000002 X07:0x000000000000004d
X08:0x0000000000000058 X09:0x0000000000000063 X10:0x000000000000000a X11:0x000000000000000b
X12:0x000000000000000c X13:0x000000000000000d X14:0x000000000000000e X15:0x000000000000000f
X1]running [23]
0010 X17:0x0000000000000011 X18:0x0000000000000012 X19:0x0000000000000013
X20:0x0000000000000014 X21:0x0000000000000015 X22:0x0000000000000016 X23:0x0000000000000017
X24:0x0000000000000018 X25:0x0000000000000019 X26[24:0x00000000000[1]running [24]
[1]running [25]
[1]running [26]
[1]running [27]
[1]running [28]
[1]running [29]
[1]running [30]
[1]running [31]
[1]running [32]
[1]running [33]
[1]running [34]
[1]running [35]
[1]running [36]
[1]running [37]
[1]running [38]
[1]running [39]
[1]running [40]
[1]running [41]
[1]running [42]
[1]running [43]
[1]running [44]
[1]running [45]
[1]running [46]
[1]running [47]
[1]running [48]
[1]running [49]
[1]running [50]
[:0x000000000000001a X27:0x000000000000001b
X28:0x0000000000000000 X29:0x0000000040067924 X30:0x000000004001a930
SPSR  :0x00000000200003c5
EPC   :0x0000000076e00601
thread           cpu bind pri  status      sp     stack size max used left tick  error
---------------- --- ---- ---  ------- ---------- ----------  ------  ---------- ---
error exception:
Execption:
X00:0x00000000000003c0 X01:0x0000000000000003 X02:0x0000000007ba07ba X03:0x00000000400435f0
X04:0x0000000000000000 X05:0x0000000000000000 X06:0x0000000000000000 X07:0x000000000000004d
X08:0x0000000000000058 X09:0x0000000000000063 X10:0x000000000000000a X11:0x000000000000000b
X12:0x000000000000000c X13:0x000000000000000d X14:0x000000000000000e X15:0x000000000000000f
X16:0x0000000000000010 X17:0x0000000000000011 X18:0x0000000000000012 X19:0x0000000000000013
X20:0x0000000000000014 X21:0x0000000000000015 X22:0x0000000000000016 X23:0x0000000000000017
X24:0x0000000000000018 X25:0x0000000000000019 X26:0x000000000000001a X27:0x000000000000001b
X28:0x0000000000000000 X29:0x00000000400674d4 X30:0x000000004001f010
SPSR  :0x00000000800003c5
EPC   :0x000000004001f06c
thread           cpu bind pri  status      sp     stack size max used left tick  error
---------------- --- ---- ---  ------- ---------- ----------  ------  ---------- ---

```
# Github issue 支持日志
![image.png](https://oss-club.rt-thread.org/uploads/20220214/d82ce2c27b2ceb87863d97a4baefde42.png.webp)

# 尝试
1. 将代码回退到 353f717037b57f663ddce9447fd05700f3087a66 版本（[libcpu/aarch64] add smp support ）依旧存在该问题。
2. 本身在2021年3月份移植过aarch64，当时贵平台还未对aarch64有很好支持，在自己完成的bsp以及libcpu的情况下，压测也同样有sem信号量压测不过的问题
3. 单线程下没有该问题
4. 在qemu-vexpress-a9平台下测试没有发现该问题(arm 32bit)

# 后果
rt-thread中malloc 等大量依赖于sem机制，如果sem压测不过将导致整个系统都有该问题，对malloc进行压测，同样导致死机异常。

GuEe_GUI 2022-02-16

这家伙很懒，什么也没写！

问题已经查清楚，该问题为gicv2的SGI中断中，中断号的10~12bit为源cpuid，而0~9bit为中断id，因此trap中需要进行清理位操作，该补丁已向上游提交，可以更新后使用，或者你也可以临时应用该补丁：
```patch
diff --git a/libcpu/aarch64/common/trap.c b/libcpu/aarch64/common/trap.c
index a648c2dd8..f828f7e01 100644
--- a/libcpu/aarch64/common/trap.c
+++ b/libcpu/aarch64/common/trap.c
@@ -148,7 +148,7 @@ void rt_hw_trap_irq(void)
     }
 #else
     void *param;
-    int ir;
+    int ir, ir_self;
     rt_isr_handler_t isr_func;
     extern struct rt_irq_desc isr_table[];
 
@@ -160,17 +160,20 @@ void rt_hw_trap_irq(void)
         return;
     }
 
+    /* bit 10~12 is cpuid, bit 0~9 is interrupt id */
+    ir_self = ir & 0x3ffUL;
+
     /* get interrupt service routine */
-    isr_func = isr_table[ir].handler;
+    isr_func = isr_table[ir_self].handler;
 #ifdef RT_USING_INTERRUPT_INFO
-    isr_table[ir].counter++;
+    isr_table[ir_self].counter++;
 #endif
     if (isr_func)
     {
         /* Interrupt for myself. */
-        param = isr_table[ir].param;
+        param = isr_table[ir_self].param;
         /* turn to interrupt service routine */
-        isr_func(ir, param);
+        isr_func(ir_self, param);
     }
 
     /* end of interrupt */

```
由于不清楚你的硬件平台具体是什么错误，所以给一份可能的解决方案，希望该修复可以解决你的问题。