fsdb2fst 段错误 rc=-11：超大 FSDB（约 2280 万 VAR）崩在 ffrLoadSignals，-l / fsdb_scopes 过滤无法规避 (SIGSEGV at load stage on huge FSDB)

[readzhan]

环境 / Environment

• wave-mcp 0.2.3（pip 离线安装 / pip offline install）；fsdb2fst 由 GitHub 仓库 third_party/fsdb2fst 源码手工构建（PyPI 包不含该源码，需从仓库补 / fsdb2fst built manually from repo source, since PyPI package does not ship it）
• FsdbReader 运行库 / runtime libs：Verdi V-2023.12-SP2，share/FsdbReader/linux64（libnffr.so + libnsys.so）
• Linux x86_64，glibc 2.29（module 加载 / loaded via environment modules），Python 3.12

触发文件特征 / Trigger file profile

• 单个 FSDB 约 112MB，timescale 1fs / single FSDB ~112MB, timescale 1fs
• VAR 总数约 2280 万，其中真实信号约 2.8 万 / ~22.8M VARs in total, ~28k real signals
• 由多段仿真 merge + 全层次 probe（高精度）产生，属于"VAR 总数超大、文件体积不大"的类型 / produced by merging multiple simulation segments with full-hierarchy probing; i.e. "huge VAR count, modest file size"

现象 / Symptom

• wave_prepare_session 直接报 rc=-11（SIGSEGV）/ returns rc=-11 (SIGSEGV) directly
• 命令行手工跑 fsdb2fst 转换同一文件，同样段错误 / running fsdb2fst manually on the same file segfaults as well

排查证据 / Investigation evidence

1. 二进制与加载环境本身正常：fsdb2fst --info 读同一文件成功（exit=0），能正确扫出 timescale 与 VAR/信号统计，说明头部解析无误 / the binary and loader environment are fine: --info on the same file succeeds (exit=0) and correctly reports timescale and VAR/signal statistics, so header parsing works
2. 曾出现 _dl_starting_up 报错，系手工运行时漏了 glibc module 环境；对齐 MCP 子进程 env 后消失，已排除配置因素 / an earlier _dl_starting_up error was caused by a missing glibc module in my manual shell; it disappeared once the env matched the MCP subprocess, so configuration is ruled out
3. 崩溃点在 libnffr 的 ffrLoadSignals：加载阶段面对超大 batch 段错误。fsdb2fst.cpp 源码注释亦写明："即使只选中 1 个信号子集，在该尺寸文件上也会崩（不能靠 -l 过滤解决）" / the crash is inside libnffr's ffrLoadSignals: it segfaults on the oversized batch at load stage. The source comment in fsdb2fst.cpp also states: "even selecting a single signal subset crashes on a file of this size (-l filtering cannot help)"
4. 实验验证：用 fsdb_scopes 过滤某个子模块子树后再转换，依然 rc=-11，与源码警告一致——过滤发生在 load 之后，而崩溃发生在 load 阶段，故任何过滤参数都规避不了 / verified experimentally: converting with fsdb_scopes restricted to one submodule subtree still yields rc=-11, consistent with the source warning — filtering happens after load, while the crash happens during load, so no filtering option can avoid it

结论 / Conclusion

非工具链误用：FSDB 的 VAR 总数超过 FsdbReader 加载处理上限时，任何转换路径（带/不带过滤）都在加载阶段崩溃。当前 fsdb2fst 对该场景无前置检查、无友好报错，表现为裸 SIGSEGV，排障成本较高。/ Not a misuse of the toolchain: once the FSDB VAR count exceeds FsdbReader's load-stage processing limit, every conversion path (with or without filtering) crashes at load stage. fsdb2fst currently has no pre-check and no friendly error for this case — just a bare SIGSEGV, which makes troubleshooting expensive.

建议 / 问题 / Suggestions & questions

1. 能否在 load 前加预检：--info 级扫描后若 VAR 数超阈值，直接给出明确报错与建议动作（切片 dump、减少 probe、避免 merge），而非段错误 / could a pre-check be added before load: after an --info-level scan, if the VAR count exceeds a threshold, emit a clear error with recommended actions (sliced dump, fewer probes, no merge) instead of segfaulting
2. libnffr 是否有分批/分段加载的 API 可规避单次超大 batch / does libnffr expose a chunked/batched loading API to avoid a single oversized batch
3. FSDB_GUIDE 能否补充 VAR 数量级上限说明与推荐 dump 策略 / could FSDB_GUIDE document the VAR-count limit and recommended dump strategies
4. 如需进一步定位，我可提供该文件的 --info 输出与生成参数描述；文件本身涉密无法直接提供 / if further diagnosis is needed I can provide the --info output and a description of the generation parameters; the file itself is confidential and cannot be shared

[readzhan]

诊断包复现结果反馈（follow-up to #1，已脱敏：不含信号名/层次路径/主机名/用户名）

TL;DR (EN): Reproduced with a real merged FSDB (1 fs, ~22.8M VARs, ~101 MB). The segfault turns out to be environment-dependent, not data-dependent: with a clean LD_LIBRARY_PATH (gcc-9 libstdc++ only) fsdb2fst --info exits 0; with glibc-2.29 libc injected into LD_LIBRARY_PATH — exactly what the MCP subprocess does via module load glibc/2.29 — it SIGSEGVs at startup (RC=139). gdb shows the crash inside the dynamic loader, before main, with no stack, and none of the ffrTimeBasedVCIterOne::ffrGetVarIdcodeXTagVCSeqNum (si_addr=0x10) frames the kit associates with its known zero-VC bug. The file is HAS_VC ($dumpvars=1, ~624k timestamp lines), so the kit's zero-VC root cause does not apply here. Suspected root cause: libc mismatch at load time (ld-2.29 vs the binary's link-time libc). Also reporting a small set -u bug in the kit's run_all.sh.

1. 测试对象与 --info 规模

• VCS 前仿导出的 FSDB，约 101 MB（2^30 字节级），timescale 1 fs；多段合并（fsdbmerge）产物，合并后时间尺度取最细
• fsdb2fst --info：scale=1fs；signals 约 2283 万（其中 real/浮点约 2.8 万；strength-skipped 0；unsupported-type 340）
• 该文件满足工具内置「>5,000,000 SELECTED」的拒载判定（规模超限）

2. 环境污染对照实验（现象复现）

运行环境（LD_LIBRARY_PATH）	fsdb2fst --info 结果
干净（仅补 gcc-9 的 libstdc++）	RC=0，正常扫描
污染（额外注入 glibc 2.29 的 libc）	SIGSEGV，RC=139（即 127+11）

与既报的 rc=-11 / SIGSEGV 现象一致。这也解释了此前的观察：手工不带 glibc module 运行 --info 成功，而 MCP 内的 wave_prepare_session（子进程 env 为 Python 加载了 glibc 2.29）必崩。

3. gdb 证据：启动期崩溃

污染环境下 gdb 报告：

• During startup program terminated with signal SIGSEGV, Segmentation fault.
• No stack.

即崩溃发生在动态链接/加载阶段、main 之前，加载器段错误。此文件没有出现贵诊断包所依据的往期崩溃帧 ffrTimeBasedVCIterOne::ffrGetVarIdcodeXTagVCSeqNum（si_addr=0x10），因此两类问题表现不相同。

4. zero-VC 判定：不适用

用 Verdi 自带 fsdb2vcd 全量导出后计数：

• $var 声明数：约 2283 万
• $dumpvars 段数：1（存在初始值 dump）
• 时间戳 # 行数：约 62 万（存在大量值变化）

判定 HAS_VC，不是 zero-VC 文件；按贵包逻辑（HAS_VC → this root cause does not apply），zero-VC 根因对本文件不适用。

5. 对开发者的补充判断与问题

• 崩溃发生在 load 之前的动态链接阶段，疑似本地编译二进制与被注入的 glibc-2.29 libc 不匹配（加载器 ld-2.29 段错误）
• 建议优先排查 tool 侧子进程的 LD_LIBRARY_PATH 被注入旧/新 libc 的情况，而非 FSDB 数据本身的 zero-VC
• 问题：在与运行环境相同的 glibc（2.29）下编译 fsdb2fst 是否为推荐修复方向？或者 server 在 spawn 转换器子进程时是否应净化 LD_LIBRARY_PATH（剥离 glibc 条目）？

6. 附：诊断包脚本 bug（供修复）

run_all.sh 在 set -u 下声明空数组 PASSTHRU=()，随后使用 ${PASSTHRU[@]:-}；未传额外参数时于 Part 2 处报：
line 62: PASSTHRU[@]: unbound variable 并中断执行。
建议将用法改为 "${PASSTHRU[@]+"${PASSTHRU[@]}"}" 或先赋非空值；绕行办法：直接调用 check_zero_vc.sh。

建议关键词

RC=139 / SIGSEGV / 启动期崩溃 / 非 zero-VC / LD_LIBRARY_PATH 注入 libc 不匹配