这几天在一台源端机器上的内网长连接服务经常遇到一个网络问题：收包正常，发包卡住。卡住时43112长连接的Send-Q持续堆积，抓包能看到IP Total Length=1500的TCP包不断重传。
用ping -M do -s 1472探测目标机器时，Linux收到mtu=1476的错误并更新本地PMTU缓存。缓存更新后，业务连接发包变小，服务恢复。
这说明原因不在应用没有读socket，也不是本机网卡丢包。更合理的解释是：源端机器到部分10.x目标的路径实际只能通过1476字节IP包，但TCP连接一开始仍按1500字节IP包发送。长期看，要么让路径上的PMTU发现稳定工作，要么在主机或网关上明确限制这条路径的MTU策略。
某 C++ 服务在运行期启用 gperftools CPU profiling 后停止响应：profile 文件创建成功，但一直保持 0 字节；服务心跳不再推进，监控进程随后因心跳超时生成 core。看起来像 profiler 没写出文件，实际是服务线程已经卡死在一次采样里。
根因方向是 profiler 在信号处理函数里做了不完全信号安全的调用栈采样，和业务线程当时正在执行的异常处理路径撞到一起，最终形成同一线程重入同一把内部锁的死锁。
规避上有完全规避和部分规避两类手段。本文结论是优先评估 GCC/libgcc 运行时升级；unwind_safeness_helper 只能作为特定构建下的定制兜底，不建议当成通用推荐方案。
2026-06-11 更新： 土耳其区 ChatGPT Plus 新开订阅价格已经从
₺499.99涨到₺999.99，相当于翻倍；按当前汇率折算后已经超过 20 美元，不再是低价首选。这次涨价主要影响新开订阅；已经订阅的老用户按原订阅续费暂时无影响。相同的转区、切店面、余额订阅流程，同样也适用于其他低价区，最终选哪个区以 App Store Price 的实时订阅比价为准。目前看到更便宜的是菲律宾区，约
109 RMB，其次是巴基斯坦区，约119 RMB，下面第二张图来自这个 ChatGPT Plus 全球比价页面。
2026-05-04 更新： 很多人反馈在付款方式页面看不到 None / 无。这个问题优先按网络环境处理：从「网页端把账号区域改成目标低价区」这一步开始，就必须使用稳定的非大陆代理 IP，并开启全局代理 / 全局模式。不要只给浏览器开代理，也不要使用规则分流。否则 Apple 可能会按当前出口或分流后的请求判断区域，导致
None / 无不显示，或转区流程异常。如果网页端始终看不到
None / 无，可以尝试改用 Mac App Store → 账户设置 → Country/Region 修改地区。部分用户反馈 Mac App Store 更容易出现None / 无，但它仍然依赖稳定、干净的非大陆出口 IP，不是替代全局代理的万能办法。参考：LINUX DO 土区教程、LINUX DO 老号换区经验、LINUX DO 踩坑记录，以及 Apple 官方 Mac App Store 修改国家或地区说明。
适用场景：先注册一个中国大陆区 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一般读取一个叫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++的混合脚本上，问题爆发了，由于申请内存是一个部门的模块，释放内存又是另外一个部门的模块，跨部门协作下的内存排查太过困难了
因此还是需要从平台侧解决这个问题
本文的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上操作的，首先在https://hub.docker.com/search?q=gcc5&type=image找到想要的镜像，然后拉镜像运行（https://github.com/dongyubin/DockerHub看下可用的代理）
1 | ~ docker pull proxy.vvvv.ee/conanio/gcc5 |
随后登陆安装ssh基础依赖
最近框架接json schema的需求，因此对其进行了调研
star最多的两个库https://github.com/pboettch/json-schema-validator和https://github.com/danielaparker/jsoncons（已完成）
| json-schema-validator | jsoncons | |
|---|---|---|
| 规范支持 | Draft 7 | Draft 7，Draft 2019-09，Draft 2020-12 |
| 字符串格式检查器 | 没有预设，都要自己实现 | 支持date，email，tcp等常见的数十种 |
| 外部依赖 | C++11起，依赖github.com/nlohmann/json |
C++20起 |
| 更新频率 | 253 commits，7 months ago | 12335 commits，yesterday |
总体而言，jsoncons会更好（规范支持全面，功能多，更新频率高），但是接入难度更高（依赖C++20，框架要兼容C++11的钉子户用户）
json-schema-validator基本功能都有，凑活够用，所以还是先接入json-schema-validator，对其进行源码分析
