极客工场

Appearance

共 2,682 字预计阅读约 9 分钟

Calibre 段错误崩溃怎么办：Segmentation fault 排错速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre（DRC/LVS/PEX）最让人心里没底的报错形态，是跑了几十分钟后 transcript 戛然而止，shell 里只留一句 Segmentation fault 或 Aborted (core dumped)——没有错误码、没有规则行号，结果库写了一半。和「挂住不退」不同，崩溃是进程已经死了，排查要从死因倒查：退出码、内核日志、transcript 最后一条规则。不退出只挂住的形态见 Calibre 运行卡死/超时速查，流程背景见 Calibre 物理验证实操，排错总入口见 开源 EDA 报错排错中心。

本文要回答的问题 ​

  • Segmentation fault、Aborted (core dumped)、进程直接消失，三者死因有什么不同？
  • 怎么判断崩溃是内存/OOM、磁盘写满，还是规则 deck 或工具本身的问题？
  • transcript 最后打印的那条规则名有什么用？
  • 大芯片 flat 模式一开多线程就崩，先动哪里？
  • 怀疑是 Calibre 缺陷，给厂商提单前要备齐哪些东西？

一、报错原文与现象 ​

1. 典型崩溃横幅：transcript 停在某条规则上，shell 兜底打印信号死因。

text
// RULE: metal5.width  (checking ...)
// Processing cell: u_ana_top/amp ...
Segmentation fault (core dumped)
text
terminate called after throwing an instance of 'std::bad_alloc'
Aborted (core dumped)

前一种是 SIGSEGV（空指针/野指针/栈溢出类），后一种是申请内存失败后自杀（SIGABRT）。两者共同点是 transcript 最后一条 // RULE: 或 cell 名离崩溃点最近，是后续二分的导航标。

2. 进程消失但没有任何横幅——先看退出码，再看内核日志。

bash
calibre -drc -hier rule.svrf > run.log 2>&1
echo $?
# 139 = 128+11  SIGSEGV 段错误
# 134 = 128+6   SIGABRT 异常中止（常见 bad_alloc）
# 137 = 128+9   SIGKILL，绝大多数是 OOM killer 或调度系统杀的

139、134 是进程自己崩的；137 是被外部杀死的，不要往工具缺陷方向查，立刻翻内核日志：

bash
$ dmesg | tail -20
Out of memory: Killed process 12345 (calibre) total-vm:...,
anon-rss:... ; Killed process 12400 (xcalibrate)

dmesg 里有 Out of memory: Killed process ... (calibre) 或 (xcalibrate)（xcalibrate 是 Calibre 的实际执行引擎），死因就是内存耗尽，与段错误无关。

二、现象 → 原因 → 处置速查表 ​

现象最常见原因处置
退出码 137，dmesg 有 OOM 行flat 模式大芯片层次展开撑爆内存；-turbo 线程过多叠加每核内存占用改 -hier、降 -turbo N、换大内存机或拆区域跑
退出码 137，dmesg 无记录LSF MEMLIMIT 或同机争抢被杀bhist -l <jobid> 看事件，申报内存限额
报 No space left on device 后中止/tmp、$TMPDIR 或 SWDB 结果目录写满指空间余量，临时目录与结果库换大盘
139/134 总停在同一条规则deck 递归 INCLUDE、宏无限展开，或某条规则触发引擎缺陷二分注释规则，定位到具体 rule/宏
换 PDK 或升级后全员崩新 Calibre 跑老 deck（或反之）的 SVRF 语言兼容问题查 PDK 支持的 Calibre 版本区间，换匹配版本
固定在某个 cell/某块图形崩GDS/OASIS 损坏：cell 循环引用、层次环、截断换输入源或用工具修库，最小几何 case 复现
跑到 PEX/license 阶段突然崩license 守护进程中途断开，xcalibrate 心跳失败查 mgcld/lmgrd 日志与网络，见 license 专篇
换台机器就不崩平台/glibc/内核版本兼容或 limits 差异diff 两机环境与 ulimit -a
各版本各机器都崩且 case 极小确属 Calibre 缺陷保留 core，calibre -br 打包提单

三、排查决策树 ​

分诊只问三件事：退出码是哪一类、dmesg 有没有 OOM、transcript 尾行停在哪。

eda/ts-calibre-segfault-crash.md D2 示意图

读这张图抓住一条主线：红色入口之后先按退出码分通道——137 走「资源通道」查内存、线程、磁盘，139/134 走「规则通道」按尾行二分；只有修复动作（橙）在各版本、最小 case 下仍然崩，才进入紫色的提单收尾。 蓝色全是排查动作，绿色表示真实 deck 完整跑通才算闭环。顺序不要反：环境没排干净就提单，厂商只会把 OOM 的 core 退回来。

四、逐条排查展开 ​

内存是 Calibre 崩溃的第一杀手，而且常常不是工具的锅。 flat 模式下大芯片会把层次几何拍平，内存随面积陡增；-turbo 多线程时每核都有独立的工作集，线程数乘以每核内存占用才是真实峰值，相关每核内存约束变量（如 CALIBRE_PERCORE_MEMORY）设得不合理也会让引擎提前异常。处置按代价从低到高：先 -turbo N 把线程降到机器物理核数与内存都扛得住的值，再把 -flat 改成 -hier（层次化验证，大芯片的常规姿势），还不行就按 layer 或区域拆 runset 分块跑。LSF 作业同时核对队列内存限额，OOM 与 MEMLIMIT 的区分点在 bhist -l <jobid>。

磁盘写满常伪装成「莫名崩溃」。 Calibre 运行中要写三处：/tmp（或 $TMPDIR）下的临时文件、运行目录里的 SWDB/结果数据库、transcript 与报告。任何一处所在分区写满，引擎的写操作失败后可能直接 abort，现象随版本不同可能是报错退出也可能只剩一句信号死因。df -h 看三个目录各自的分区余量，把 $TMPDIR 和结果目录指到本地大盘，别放配额紧张的 NFS 家目录。

139/134：尾行规则名就是二分坐标。 transcript 最后一条 // RULE: 与 cell 名记录了崩溃前引擎正在处理什么。规则侧两个典型自找的坑：一是 INCLUDE 形成环或宏在展开中引用自己导致无限展开，二是单条规则在极端几何上触发引擎边界。做法是把 deck 复制一份，从尾行规则附近开始二分注释、对同一块版图重跑；规则文件的组织与宏写法见 SVRF rule deck 结构解剖。LVS 侧若总崩在器件识别阶段，还要怀疑抽取层与器件定义本身，对照 LVS 器件识别与抽取 缩小范围。

版本匹配：PDK deck 不是跨版本通用的。 用 2024 版 Calibre 跑 PDK 在 2014 年前后交付的老 deck，SVRF 语法语义的变迁可能让解析器或执行引擎崩在奇怪的位置；反向搭配（老引擎跑新 deck 的新语法）更常见。PDK 文档一般写明支持的 Calibre 版本区间，先核对它，再用相邻版本各跑一次最小 case——旧版不崩新版崩，回退版本先保流片，同时把问题报给厂商。

输入数据损坏造成固定位置崩溃。 GDS/OASIS 里出现 cell 循环引用（A 引用 B、B 又引用 A）、层次环或文件截断，Calibre 展开层次时可能栈溢出或访问非法地址，特征是总崩在同一个 cell。判别方法：绕开整片宏，只导入该 cell 单独跑；确认数据问题后回上游重新导出 GDS，不要在损坏的输入上反复重试。超深嵌套的合法层次偶尔也会顶穿引擎栈，这属于工具缺陷，按下面的提单路径走。

跑到一半 license 断连是另一种「中途崩」。 启动签到正常、运行中 mgcld 重启或网络中断，xcalibrate 的心跳失败可能表现为进程异常退出而不是干净的 license 报错。查 license server 日志与本机网络，排除后重跑；签到链路（MGLS 错误码、mgcld 状态）的完整排法见同系列的 Calibre license 专篇。

确认是工具缺陷：core 与 support 包是入场券。 各相邻版本都崩、case 已剪到单个 cell 加几条规则，就按厂商支持流程走：保留 core 文件（压缩归档，别删）、完整 transcript、deck 与最小输入数据，并用 Calibre 自带的缺陷信息收集方式生成环境包（calibre -br -ssv，具体参数以本单位安装的版本文档为准），随单附上版本号、平台、glibc/内核版本与「换版本对照」结论。可复现的小 case 加完整现场，厂商响应速度会快一个数量级。

五、预防与纪律 ​

  • 内存预算先于提交：按版图面积估 flat 展开峰值，-turbo 线程数乘以每核工作集不超过物理内存，大芯片默认走 -hier。
  • 三处写盘目录先检查：开跑前 df -h 核对 /tmp、$TMPDIR、SWDB 结果目录所在分区，跑批把临时目录显式指到本地大盘。
  • deck 变更走小 case 回归：新规则、新宏先在小 deck 上验证再进流片 deck；公共宏禁止自引用式递归。
  • PDK 与工具版本成对锁定：升级 Calibre 前先核 PDK 支持区间，旧版安装保留一段时间用于对照定位。
  • 崩溃现场固定归档：core（压缩）、完整 transcript、退出码与 dmesg/bhist -l 记录三件套留齐，再决定重跑还是提单。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇中「Calibre 进程崩溃」节点的 FAQ 页：进程不退出但不出结果见 Calibre 运行卡死/超时速查，规则文件本身的结构见 SVRF rule deck 结构解剖，LVS 抽取侧背景见 LVS 器件识别与抽取，正常验证流程见 Calibre 物理验证实操，更多报错主题从 开源 EDA 报错排错中心 进入。

一句话总结 ​

Calibre 中途崩溃先看退出码与 dmesg：137 是被外部杀死，OOM 行指向内存耗尽就降 -turbo、改 -hier、拆区域，写盘报错就给 /tmp 与 SWDB 换大盘；139/134 才是引擎自身崩，按 transcript 最后一条规则名二分 deck、排查递归 INCLUDE 与无限宏展开，固定 cell 崩查 GDS/OASIS 层次环，升级后崩先核 PDK 与 Calibre 版本匹配区间，运行中断连查 mgcld；相邻版本都崩且最小 case 可复现，才带 core、完整 log 和 calibre -br 信息包提缺陷单，防复发靠内存预算、写盘预检、deck 小 case 回归与版本成对锁定。