wdfk-prog
> 另外测试了下littlefs，发现会有这样的问题： > > open同一个文件多次后，在close的第二次会出现断言，问题截图： > > > static void lfs_multi_open_repro_case(void) > { > int fd_primary = -1; > int fd_secondary = -1; > > fd_primary = open(TEST_FILE_PATH, O_RDWR |...
> 使用qemu-a9的BSP测试了下，发现貌似没这个问题？ > > > 测试代码： > > #include > #include > > #define LEAK_TEST_FILE "/elm_leak_test.txt" > #define LEAK_TEST_PASSES 50 > > static void dump_heap_usage(const char *tag, rt_uint32_t *used_out) >...
> [@wdfk-prog](https://github.com/wdfk-prog) 测试了下，还是没能复现 > > master分支，qemu-a9: > > > 5.1.0分支： > > - 有一个地方open该文件还为close的情况下,进行cat该文件吗? - 可以在` if (file->vnode->ref_count > 1)`里面加个打印看看是否直接退出了? ```c int dfs_elm_close(struct dfs_file *file) { FRESULT result; RT_ASSERT(file->vnode->ref_count >...
> > > [@wdfk-prog](https://github.com/wdfk-prog) 测试了下，还是没能复现 > > > master分支，qemu-a9: > > > > > > 5.1.0分支： > > > > > > > > > > > * 有一个地方open该文件还为close的情况下,进行cat该文件吗? >...
> > > > > [@wdfk-prog](https://github.com/wdfk-prog) 测试了下，还是没能复现 > > > > > master分支，qemu-a9: > > > > > > > > > > 5.1.0分支： > > > > > >...
> 系统异常时，是不是不使用 ulog 打印更好呢？毕竟系统都跑飞了，一些系统状态可能都是不对的，直接用 ulog 导致的连锁反应挺多的，可靠性严重不足。之前的 CMB 日志前端直接用 ulog ，现在看有些草率。 > > 两个小建议： > > * 如果只是想拿到 ulog 异步缓冲区的未日志，那可以直接造个高可靠的迭代接口给到异常环境去取； > * 异常时，如果想存储更多系统信息 > > * 日志后端一定要选择可靠的，最好都不要用文件系统，直接存储到程序状态依赖少的裸介质（裸 emmc 分区、PSRAM 分区、norflash 分区等），下次开机后再进行文件转存...
- 增加异常输出后,打印一次线程列表 - 因为线程溢出的话,查看当前溢出线程的大小,更容易进行调整
> @wdfk-prog CI的报错问题需要修复一下 - 已修复.未考虑到没有开启ULOG的情况
- 使用format格式化解决CI错误
> 我觉得这个 PR 改动过于复杂，有些违背 ulog 的设计初衷。异常日志，希望不要使用 ulog 进行输出。 - 异常日志可以选择用ulog或者不用ulog这个是一回事. - ulog能不能支持这种情况的调用又是另一回事. - 没有这种改动的话,ulog在同步的情况下输出是没问题的;但是在异步开启的情况下是有问题的. - 这个pr等于是给用户多了一个选择 - 另外如果异常日志不使用ulog进行输出的话,想要将异常日志保存到文件系统或者存储介质上的话.得重新做一套,这个更加复杂与不合适吧😢