每请求漏一个 CExp，与 512 层嵌套

# 每请求漏一个 CExp，与 512 层嵌套

这一篇讲两个**都不报错**的 bug。一个让进程的 RSS 随请求数线性上涨，泄漏量小到你不会注意到；另一个平时完全正常，直到有人递来一份嵌套几千层的 JSON 把它炸崩。它们都在 2026-09-18/19 两天里被修掉了。

## 第一笔：每次短路，都新建一个格子

Fun 的解释器里，`x?`(可选求值)和 `s[i]`(字符串下标)走到某条路径时，会需要一个「空值格子」：

```fun
nosuchname?.foo?    // 每次求值: 漏一个 CExp
s[0]                // 每次读: 漏一个 CExp
ps?.@count?()       // zillio rdb 每请求都走这条
```

旧代码在基名为 nil、或字符串下标取值时，直接 `CExp.new(nil)` 造一个新格子交出去。问题在于接收它的 `evar` 是**借用字段** —— `Destroy` 里不会 `del` 它。于是每一次求值都漏掉一个 `CExp`，而且永远不会还回操作系统。

泄漏量小得可以藏很久。仓库里的实测(20000 次循环，RSS 增长)：

| 表达式 | 修复前 | 修复后 |
| --- | --- | --- |
| `nilv?.@count?()` | +1.8 MB | 0 |
| `nosuchname?.foo?` | +2.1 MB | 0 |
| `s[0]` | +3.2 MB | 0 |
| `arr[99]`(越界读) | 0 | 0 |
| `nilv`(普通赋值) | 0 | 0 |

为什么以前没被发现：这些分配只发生在 nil 短路与字符串下标两条路径上，命中缓存的正常路径走的是 set/class 查表，根本不经过这里。而在真实业务里，fun-zillio 的 rdb 后端每个请求都会踩中(lib-ado 的 `ps?.@count?()`、lib-orm 的 `v?.@count?()`)，于是 RSS 随请求数线性增长，每 `RdbGet` 约 +0.7 KB、每 `LdbGet` 约 +1.6 KB，重复跑结果一致。

修法不是「记得 del，而是别再分配」：给三个位置各准备**一个**格子(`CId.enil` / `CId2.eopt` / `CIdx.estr`)，交出去之前把值重置为 nil，在 `Destroy` 里释放。从 Fun 层看，fresh cell 与复用 cell 的观测行为完全相同 —— 格子不可达、值都是拷贝出去的 —— 少掉的只有分配。

## 第二笔：解析是迭代的，释放是递归的

第二笔更朴素：解析器扫描 JSON/FD 时用的是迭代写法，不会因为嵌套深而爆栈。但它建出来的**树**在释放、克隆、序列化时是递归遍历的。也就是说，一份把 `[` 或 `{` 叠上几千层的文档，解析能过，之后某个时刻递归一释放 —— 栈溢出，进程挂掉。这是标准的 DoS 面：攻击者不需要让你写出错误的结果，只需要让你崩。

修法直接给嵌套设上限：超过 **512** 层就释放掉半成品树并抛异常。

```fun
// 超过 512 层嵌套时,不再构建出无法释放的结构:
// nesting too deep (max 512)
```

512 这个数远深于任何真实文档需要的层数，所以它拦下的基本只有攻击载荷。JSON 扫描与 FD 扫描(`libfd.inc`)共用同一条限制。

## 共同点

两笔代价的形态不同 —— 一个是「慢慢涨」，一个是「一下子崩」 —— 但根子是同一个：**出错的地方不是抛异常的地方，而是没人看着的地方**。

- 泄漏发生在「反正结果是 nil」的短路上，没人会觉得这里需要管内存；
- 爆栈发生在解析**成功之后**的释放阶段，没人会觉得一份合法文档有危险。

所以两个修复也都不是「加个 if」那么简单，而是改变默认行为：该复用的格子只分配一次；该拒绝的深度当场拒绝。验证同样走了完整回归:`run-linux-regression.sh` 87/87，演示程序与改动前二进制逐项对比(只有打印耗时的 lib-time-test 因非确定性不同)，另有两个一次性探针对 12 个语义用例(含旧的 `a?.x?` 取值、字符串下标、链式 `?.`)逐字符比对，并确认三处内存曲线全部拉平。

## 一句话总结

最贵的 bug 不是报错的那个，而是那个**不报错的**：它要么每请求偷走 0.7 KB，要么攒到 512 层才第一次翻脸。