太长不看版

某 C++ 服务在运行期启用 gperftools CPU profiling 后停止响应：profile 文件创建成功，但一直保持 0 字节；服务心跳不再推进，监控进程随后因心跳超时生成 core。看起来像 profiler 没写出文件，实际是服务线程已经卡死在一次采样里。

根因方向是 profiler 在信号处理函数里做了不完全信号安全的调用栈采样，和业务线程当时正在执行的异常处理路径撞到一起，最终形成同一线程重入同一把内部锁的死锁。

规避上有完全规避和部分规避两类手段。本文结论是优先评估 GCC/libgcc 运行时升级；unwind_safeness_helper 只能作为特定构建下的定制兜底，不建议当成通用推荐方案。

现象：开启 CPU profile 后服务停住

适用场景：先注册一个中国大陆区 Apple ID，然后把账号国家/地区改成土耳其区，用于通过土区 App Store 礼品卡余额订阅 ChatGPT Plus。
核心思路：注册国区账号 → 网页端转区到土耳其 → 手机端切 App Store 店面 → 登录并下载免费 App 固定店面 → 购买土区礼品卡 → 兑换余额 → 再订阅。

这套流程的目标是准备一个可以稳定走土区 App Store 内购的 Apple ID，然后在 ChatGPT App 里用 Apple 账户余额订阅 ChatGPT Plus。土耳其区只需要把目标国家、账号入口和 App Store Scheme 换成土耳其即可。

不建议拿主力 iCloud 账号操作。更推荐单独注册一个只用于 App Store、礼品卡充值和订阅的 Apple ID。

开始前准备

太长不看版

这个问题发生在 nydusd 重新挂载镜像的时候：第一次挂载后路径能访问；卸载后再挂回同一条路径，直接访问有时会提示“不存在”。但如果先对它的父目录执行一次 ls -l，再访问原来的路径，它又能恢复。

ls -l 这里不是普通的“看一眼目录”。它会在读父目录名字的同时，继续读取子项属性；这会让内核重新拿到当前的“这个名字现在对应哪个对象”。这部分机制正文会先用一个最小 FUSE demo 展开。

根因是卸载时，nydusd 需要告诉内核：“这个父目录下面的某个名字已经变了。”原来的代码通知发错了位置，内核还记着旧的名字关系，所以直接按路径访问时会走到旧状态。修复就是把通知发到正确位置：不要把整条挂载路径当成一个名字，而是用“直接父目录 + 最后一级名字”去通知内核。

正文的走法是：先看现象和一个最小 FUSE demo，再回到 nydusd 的真实路径结构和源码修复。

core文件使用gdb来dump线程堆栈是很简单的事情，但是dump协程就有点困难了

因为gdb本身不知道协程的数据结构，本文记录了如何解决这个问题

协程的背景在我以前的博文在 C++ 中实现协程已经详细写过了，不再赘述

首先深入协程切换的原理

协程切换原理

MCJIT是无法进行pprof的，原因先要了解下pprof原理

pprof原理

pprof一般读取一个叫hprof后缀名的文件

一个典型的例子是https://github.com/tedcy/tcmalloc_hook_debug/blob/master/tcmalloc_miss_mmap_hook/main.cpp

dump出来的allbin.hprof格式如下

自研serverless平台存在一个问题很多年了，引入cpython以后，就不能使用tcmalloc了

否则会直接coredump，这个问题不解决，使用平台的同学就没办法进行内存泄露分析

在一个多部门组成的python和C++的混合脚本上，问题爆发了，由于申请内存是一个部门的模块，释放内存又是另外一个部门的模块，跨部门协作下的内存排查太过困难了

因此还是需要从平台侧解决这个问题

coredump问题

本文的llvm版本，是基于llvm7.1.0的release包添加了一些利于理解的日志，没有改功能，已经上传到github：https://github.com/tedcy/llvm7_test

在conanio/gcc5:2.91的镜像版本，使用项目中的build.sh就能编译

类图

RuntimeDyldImpl是RuntimeDyld的PIMPL模式，因此省略了RuntimeDyld

类图里面有让人眼花缭乱的MemMgr和Resolver传递，实际上都是指向的RTDyldMemoryManager

昨晚又整ssh配置整了半天，记不清楚是第几次踩坑了，还是需要整理一下问题的处理思路

docker配置

我是在docker上操作的，首先在https://hub.docker.com/search?q=gcc5&type=image找到想要的镜像，然后拉镜像运行（https://github.com/dongyubin/DockerHub看下可用的代理）

1
2

~ docker pull proxy.vvvv.ee/conanio/gcc5
~ docker run -it -p2222:22 proxy.vvvv.ee/conanio/gcc5 /bin/bash

随后登陆安装ssh基础依赖

最近框架接json schema的需求，因此对其进行了调研

star最多的两个库https://github.com/pboettch/json-schema-validator和https://github.com/danielaparker/jsoncons（已完成）

总体而言，jsoncons会更好（规范支持全面，功能多，更新频率高），但是接入难度更高（依赖C++20，框架要兼容C++11的钉子户用户）

json-schema-validator基本功能都有，凑活够用，所以还是先接入json-schema-validator，对其进行源码分析

当前的一致性哈希存在四个bug，分别进行分析

以这个版本https://git.huya.com/server_arch/taf/-/blob/924950284557f183bd025ed758dc2e878ae36938/src/libservant/EndpointManager.cpp#L2448为例

我新增了部分日志，总体流程的关键代码在getConHashProxyForNormal

他的输入是hashCode（也就是prx->taf_consistent_hash(hashCode)传入的），输出是本次负载均衡选出的节点指针

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

AdapterProxyPtr EndpointManager::getConHashProxyForNormal(int64_t hashCode)
{
    //_vLastConHashProxys是上一次更新一致性哈希时记下的节点
    //checkConHashChange中如果当前节点和上一次的有变化，那么返回true
    if(checkConHashChange(false, _vLastConHashProxys)) {

        //根据当前节点，把数据写入到_consistentHash
        updateConHashProxyWeighted(true, _vLastConHashProxys, _consistentHash);
    }
    LOG_INFO << "[TAF][EndpointManager::getConHashProxyForNormal _sObjName:"
             << _sObjName
             << "|_consistentHash.size():" << _consistentHash.size() << endl;

    if(_consistentHash.size() > 0) {
        //根据_consistentHash数据一致性哈希选节点
        ...

        //没选出来，返回空
        return nullptr;
    }
    //_consistentHash是空的，降级到普通hash

    return getHashProxyForNormal(hashCode);
}