适用场景：先注册一个中国大陆区 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 的这个问题里，现象是：第一次挂载后，一个路径比如 /a/b/c 还能正常访问；经历一次 unmount / remount 以后，再去访问它会提示“这个路径不存在”；但如果先对它的父目录做一次 ls -l /a/b，再回头访问 /a/b/c，它又好了。
• 原因是：nydusd umount 时，那条挂载点入口的失效通知没有发到正确的“直接父目录 inode + 单个 entry name”上，内核于是还沿用了旧的名字状态。后面 ls -l 之所以能把它救回来，是因为它会继续触发更强的父目录读取和子项属性访问，把当前的名字和对象关系重新交回内核。
• 修复点是：nydusd 不要把整条挂载路径当成一个名字去发失效通知，而是要对挂载点最后一级名字，按它的直接父目录 inode 和 basename 去发。

这篇文章先不从具体系统讲起，而是先整理一个很绕的路径问题。

如果第一次读到 FUSE，可以先把它理解成：文件系统逻辑主要跑在用户态，内核通过一套接口和它配合。

前四节先只讲这个 bug 本身、FUSE 背景和一个最小 demo，不急着抛真实系统名字。到第 5 节，再回到真实场景，看它为什么会落到 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);
}

在Serverless平台的研发过程中，意外在python的import问题上踩坑了

大概还是对python的包管理基本原理不够了解，首先对python的包管理机制做一个总结，然后分析这一次踩坑的问题

python的包管理

Import基本语法

Python 中 import 有四种常见语法形式：