[Bug] k230 utest opencv 19_getStructuringElement 运行出错 #9902

Activity

1. unicornx

   added

   Arch: RISC-VBSP related with risc-vBSP related with risc-v

   on Jan 13, 2025
2. Rbb666

   added

   BSP: K230BSP related with K230BSP related with K230

   on Jan 13, 2025
3. heyuanjie87 commented on Jan 15, 2025

   

   heyuanjie87

   on Jan 15, 2025

   Contributor

   More actions

   让lwp_munmap直接返回，运行不崩溃，问题范围可以大概锁定在lwp_mmap2和lwp_munmap之间

   

   
4. heyuanjie87 commented on Mar 5, 2025

   

   heyuanjie87

   on Mar 5, 2025

   Contributor

   More actions

   目前这个问题取得了一些比较有帮助的调试信息：
   出问题的地址由malloc调用mmap分配，其中前64字节用于malloc的管理算法，后面部分由用户使用。
   musl如下：

   void *malloc(size_t n)
   {
   	struct chunk *c;
   	int i, j;
   
   	if (adjust_size(&n) < 0) return 0;
   
   	if (n > MMAP_THRESHOLD) {
   		size_t len = n + OVERHEAD + PAGE_SIZE - 1 & -PAGE_SIZE;
   		char *base = __mmap(0, len, PROT_READ|PROT_WRITE,
   			MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
   		if (base == (void *)-1) return 0;
   		c = (void *)(base + SIZE_ALIGN - OVERHEAD);
   		c->csize = len - (SIZE_ALIGN - OVERHEAD);
   		c->psize = SIZE_ALIGN - OVERHEAD;
   		return CHUNK_TO_MEM(c);
   	}
   }
   

   由此可见前64字节区域是必定最先被写入的，也就是理论上前面64字节区域最先发生page-fault异常。
   然而实际与预期有所不同：出问题的页page-fault地址在64字节之外(也就是首次写入成功时物理页还没被映射)

   下面是日志：

   /* 打印page-fault地址 */
   int rt_aspace_fault_try_fix(rt_aspace_t aspace, struct rt_aspace_fault_msg *msg)
   {
       int err = MM_FAULT_FIXABLE_FALSE;
       uintptr_t va = (uintptr_t)msg->fault_vaddr;
       if (va >= 0x618000 && va < 0x100000000) //过滤掉一些不关心的地址
       {
           rt_kprintf("fault addr %p\n", va);
       }
   }
   

   mmap addr = 0x0000000000618000, 41000 /* 在mmap系统调用中打印分配到的地址 */
   fault addr 0x0000000000618018 /* 正常情况 */
   fault addr 0x0000000000658642
   
   mmap addr = 0x00000000007da000, 181000
   fault addr 0x00000000007da018 /* 正常情况 */
   
   mmap addr = 0x0000000000618000, 41000
   fault addr 0x0000000000618243  /*  page-fault地址不在预期范围 */
   fault addr 0x0000000000619000
   munmap addr = 0x0000000000618030 length = 0[I/mm.aspace] rt_aspace_unmap_range(addr=0x0000000000618030): Unaligned address
   
5. heyuanjie87 commented on Mar 10, 2025

   

   heyuanjie87

   on Mar 10, 2025

   Contributor

   More actions

   退出时清理dcache后不出现未对齐的问题，但是第二次运行时出现了其它更严重的问题

   
6. heyuanjie87 commented on Mar 10, 2025

   

   heyuanjie87

   on Mar 10, 2025

   Contributor

   More actions

   #10100

   在deepseek的提示下五秒定位了问题

   DeepSeek-V3
   CPU的数据缓存（DCache）采用 PIPT（Physically Indexed, Physically Tagged） 策略的优缺点如下：
   
   /* 其它删除了留下了下面关键提示 */
   缺点
   延迟增加 ：
       需先完成虚拟地址到物理地址的转换，增加了访问延迟。
   
   

   下面是修复后k230测试日志(无异常信息):

   msh />19_getStructuringElement.elf
   msh />[W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   
   msh />19_getStructuringElement.elf
   msh />[W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   
   msh />19_getStructuringElement.elf
   msh />[W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   
   msh />
   msh />19_getStructuringElement.elf
   msh />[W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   [W/time] Cannot find a RTC device!
   

   👍React with 👍1Reacted by Rbb666
7. Rbb666

   added this to 单元测试（UTEST）Frameworkon Nov 7, 2025
8. github-project-automation

   moved this to Todo in 单元测试（UTEST）Frameworkon Nov 7, 2025
9. Rbb666

   removed this from 单元测试（UTEST）Frameworkon Nov 7, 2025