openwrt-aarch64_cortex-a53-static segfaults since v117

[ghost]

原来的宏定义PA_THREAD_CACHE_SUPPORTED已经变成PA_CONFIG(THREAD_CACHE_SUPPORTED)，不然在我的机器上会闪退

---------------- src/net/tools/naive/partition_alloc_support.cc ----------------
index 851c1596d5..c308cd78db 100644
@@ -122,7 +122,7 @@ void ReconfigureAfterFeatureListInit() {
 }
 
 void ReconfigureAfterTaskRunnerInit() {
-#if defined(PA_THREAD_CACHE_SUPPORTED) && \
+#if PA_CONFIG(THREAD_CACHE_SUPPORTED) && \
     BUILDFLAG(USE_PARTITION_ALLOC_AS_MALLOC)
   base::allocator::StartThreadCachePeriodicPurge();
 
@@ -153,7 +153,7 @@ void ReconfigureAfterTaskRunnerInit() {
     ::partition_alloc::ThreadCache::SetLargestCachedSize(largest_cached_size);
   }
 
-#endif  // defined(PA_THREAD_CACHE_SUPPORTED) &&
+#endif  // PA_CONFIG(THREAD_CACHE_SUPPORTED) &&
         // BUILDFLAG(USE_PARTITION_ALLOC_AS_MALLOC)
 
 #if BUILDFLAG(USE_PARTITION_ALLOC_AS_MALLOC)

[klzgrad]

没有重现。

什么环境，什么版本，具体现象是什么，有没有coredump？

[klzgrad]

不能只给结论，需要过程，这样才可能确认你描述的问题与结论的因果关系的正确。opendir与ParitionAlloc没有直接联系。

[klzgrad]

哪里的calloc。不清零具体是指什么

[zhangbo8418]

我的er-x也嘎了。。。启动不鸟。。。

[klzgrad]

•  ->ReconfigureAfterTaskRunnerInit(/*process_type=*/"");
  

•  ->ReconfigureAfterTaskRunnerInit("renderer");
  

不改有什么现象

[klzgrad]

ReconfigureAfterTaskRunnerInit("renderer")
!is_already_zeroed

这些都是现象，不是问题本质，也不应该成为修复的方法。

上面的信息中缺少从“闪退”到“分配的内存没有清零”的逻辑链条，我也无法确认。

is_already_zeroed没有被正确设置的原因又是什么，肯定是不符合PartitionAlloc设计的现象，也不应该与process_type="renderer"有必然关系。如果存在偶然的关系，需要找到必然的关系之后，才能产生正确的修复。

我在qemu里面无法重现naiveproxy-v117.0.5938.44-1-openwrt-aarch64_cortex-a53-static.tar.xz发生闪退的现象。

[klzgrad]

• auto* thread_cache = GetOrCreateThreadCache(); 你用gdb看到thread_cache是nullptr? 还是其他异常值？
• 从process_type="renderer"到thread_cache = nullptr中间有哪些逻辑步骤：
  • thread_cache = nullptr往前回溯：nullptr是GetOrCreateThreadCache 内部哪个分支生成的？可能是MaybeInitThreadCache。MaybeInitThreadCache内部，可能是ThreadCache::Create(this)，但是ThreadCache::Create()里面看不出哪种情况可以生成nullptr。所以需要你继续查明。
  • process_type="renderer"往后延伸：ReconfigureAfterTaskRunnerInit("renderer")内部使用了process_type的地方只有partition_alloc::ThreadCache::SetLargestCachedSize(largest_cached_size_)，这个调用怎样影响到ThreadCache::Create()导致无法工作？
  • “EnableThreadCacheIfSupported正确开启”：这个函数是在ReconfigureAfterFeatureListInit里面调用，与ReconfigureAfterTaskRunnerInit("renderer")没有关系。
  • EnableThreadCacheIfSupported这个函数内部也看不出存在与process_type有关的失效条件。

我这里没有重现条件，如果想解决的话，需要一起来把根因查明。

[klzgrad]

auto* thread_cache与process_type=="renderer"的关系应该与我的机器无关，可以直接在x86_64的linux上调试复现

这个在x86_64上无法重现，opendir("/etc/ssl/certs")被调用的StaticUnixSystemCerts::Create()运行时，thread cache已经完成正常初始化，在StaticUnixSystemCerts::Create()从开始到结束期间，auto* thread_cache = GetOrCreateThreadCache();都是正常的值。

/*is_performance_sensitive=*/true

这个是为了接口简单随便取的值，是false还是true都应该工作。

所以还是回到前面的问题：

设置process_type="renderer"的话，就能使EnableThreadCacheIfSupported正确开启

这个因果关系还缺少中间的逻辑步骤。

从以下调用层级看

main
  ReconfigureAfterTaskRunnerInit(/*process_type=*/"");
    EnableThreadCacheIfSupported();  

EnableThreadCacheIfSupported()是无条件开启的，与process_type没有关系。

[klzgrad]

x86_64上到现在还没有发现一种重现方法，其他平台目前也没有重现方法。main()刚开始时，thread_cache确实应该为nullptr，只有在ReconfigureAfterFeatureListInit之后thread_cache才会初始化。因为没有重现方法，所以也无法证实以上报告的现象是否属实及其影响范围。

以上也没有证实process_type=="renderer"应是这个潜在问题的正确解决方法，从PartitionAlloc的设计上判断这不应该是问题所在。

在没有更多信息证实问题发生过程之前，我无法接受以上提出的代码修改。

[ghost]

破案了，原因是内核不支持madvise，为此我专门编译了一个内核，可以在qemu-system里复现，不过过程嘛非常麻烦

[ghost]

应该是这个原因，这段patch过的代码有问题，在支持madvise的机器上，总是返回0，并且成功后再次访问时是清零的
但是不支持madvise的机器，直接return了，导致再次访问时出现了内存非零的情况，添加memset(ptr, 0 , length);就正常了

--- src/base/allocator/partition_allocator/page_allocator_internals_posix.h ---
index d540193984..6d1af2c0fa 100644
@@ -420,6 +420,7 @@ void DiscardSystemPagesInternal(uintptr_t address, size_t length) {
   int ret = madvise(ptr, length, MADV_DONTNEED);
   if (ret && errno == ENOSYS) {
     // Ignores when the kernel is built without CONFIG_ADVISE_SYSCALLS
+    memset(ptr, 0 , length);
     return;
   }
   PA_PCHECK(ret == 0);

[klzgrad]

可以在qemu-system里复现，不过过程嘛非常麻烦

可以不用想这个问题了，后面我会弄一个硬件来运行Merlin。

内核不支持madvise

这个应该是一个比较有可能的原因方向，里面的行为我在看一下

[ghost]

哦，那麻烦你了

[ghost]

v117.0.5938.44-2已经修复

[klzgrad]

请勿追加无关问题，如有问题需要另行提交

[w01230]

clang

兄弟你编译的版本我在RB5009上跑docker可以用，release的版本从114-118，从a53 generic a72都不能用，你能再帮编译下A72的版本嘛

[ghost]

有需求可以直接开贴向官方提
a72的cpu可以暂时试试这两个static版的
https://github.com/klzgrad/naiveproxy/releases/download/v118.0.5993.65-1/naiveproxy-v118.0.5993.65-1-openwrt-aarch64_cortex-a53-static.tar.xz
https://github.com/klzgrad/naiveproxy/releases/download/v118.0.5993.65-1/naiveproxy-v118.0.5993.65-1-openwrt-arm_cortex-a9-static.tar.xz

[w01230]

有需求可以直接开贴向官方提 a72的cpu可以暂时试试这两个static版的 https://github.com/klzgrad/naiveproxy/releases/download/v118.0.5993.65-1/naiveproxy-v118.0.5993.65-1-openwrt-aarch64_cortex-a53-static.tar.xz https://github.com/klzgrad/naiveproxy/releases/download/v118.0.5993.65-1/naiveproxy-v118.0.5993.65-1-openwrt-arm_cortex-a9-static.tar.xz

A53不行