极客工场

Appearance

共 1,429 字预计阅读约 5 分钟

Vivado 段错误崩溃速查：Segmentation fault 与退出码 139 怎么办 ​

更新时间：2026-10-22。FAQ 速查页，属于 FPGA 工具报错排错系列。Vivado 崩溃最难处理的地方在于它经常「不给理由」：GUI 窗口一闪就没，Tcl 控制台只剩一句 Segmentation fault，工程目录多出一个 vivado_pid*.zip 崩溃包。排查要先分清一件事——进程是自己崩的，还是被系统杀掉的，二者方向完全不同。同系列的 RTL 侧报错见 Vivado module 找不到速查，资源撑爆导致的异常见 Vivado LUT 利用率超限速查，更多 Vivado 主题从 FPGA intermediate 目录 进入。

本文要回答的问题 ​

  • 退出码 139 和 137 分别代表什么，为什么第一步必须看它？
  • GUI 闪退但 batch 模式不崩，问题出在哪一层？
  • vivado.log、vivado.journal 和 vivado_pid*.zip 崩溃包各看什么？
  • 怀疑是设计把工具搞崩的，怎么二分出最小复现用例？
  • 清缓存该删哪些目录，换版本时怎么查 Xilinx 的已知缺陷记录？

一、报错原文与现象 ​

1. Tcl 控制台或终端里的典型横幅：命令没报错，进程直接被信号打死。

text
Segmentation fault (core dumped)

batch 模式下退出码可以在 shell 里直接拿到，这是判定死因最快的办法：

bash
vivado -mode batch -source build.tcl
echo $?
# 139 = 128+11  SIGSEGV 段错误，Vivado 进程自身访问了非法地址
# 137 = 128+9   SIGKILL，绝大多数是内存耗尽被 OOM killer 杀的
# 134 = 128+6   SIGABRT，内部断言失败或申请内存失败后主动中止

2. GUI 闪退时没有控制台可看，线索全部留在工程目录的日志尾部。

bash
$ tail -n 20 /proj/demo/vivado.log
...
INFO: [Project 1-111] Completed writing XDC
Abrupt termination of the Vivado application.

同目录下通常还能看到 vivado_pid<进程号>.zip（崩溃时自动打包的现场）以及上次会话残留的 vivado.journal（本次实际执行过的 Tcl 命令流水）。Abrupt termination 说明进程是非正常退出的，但它不区分段错误与被杀——要区分仍然回到退出码和系统日志：Linux 上 dmesg | tail 或 journalctl -k 里出现 Out of memory: Killed process ... (vivado) 就是 OOM，与段错误无关。

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

现象最常见病因处置
退出码 137，dmesg/journalctl 有 OOM 行超大设计综合/实现撑爆内存，系统 OOM killer 动手加内存或加交换区应急；降并行度、拆大设计、避免一次性展开超大 parameter 结构
退出码 139，总停在综合 elaboration 阶段递归 `define 宏或 generate 块无限展开、数组/parameter 规模大到撑爆工具内部结构二分注释 module 与宏，定位自引用；给巨型数组降维或改用 BRAM 推断
139 固定发生在生成/打开某个 IP 时该版本 IP 生成器（含 block design）已知缺陷升级到同版本线最新补丁（如 2023.2 → 2023.2.1），查对应版本的 Answer Record
GUI 崩、同脚本 vivado -mode batch 不崩显卡驱动、libGL/X11 或远程 X 转发的图形栈问题用 batch 跑构建；更新显卡驱动；远程会话改 VNC/虚拟显示，不走 X 转发
升级 Vivado 或改机器后开始崩安装不完整、补丁缺失、系统库版本不匹配重装/补装补丁；核对发行版兼容清单；diff 两台机器环境
跑到一半随机崩，工程放在 NFS/网盘上网络盘锁与缓存一致性问题，.lock/journal 状态损坏工程整体迁到本地 SSD；删锁文件与 journal 后重开
任意操作都崩、新开极小工程也崩工程缓存或用户配置目录损坏（.Xil、.gen、runs/、~/.Xilinx）按第三节步骤清缓存重新生成
各版本各机器都崩且用例已剪到极小确属 Vivado 缺陷保留崩溃 zip 与最小工程，通过官方支持渠道提单

三、排查决策树 ​

分诊只做三件事：拿退出码、读日志尾行、用 batch 复跑分流。下面这张图对应实际顺序，颜色含义是：红=崩溃入口，蓝=排查动作，橙=修复动作，绿=冒烟通过。

fpga/intermediate/ts-vivado-segfault-crash.md D2 示意图

读这张图抓住一条主线：红色入口之后先按退出码分通道——137 走资源通道查内存，139 才是工具自身崩，按 vivado.log 尾行二分；橙色修复做完必须回到绿色的 batch 冒烟节点，batch 不通过就不算闭环。 顺序不要反：内存没排干净、缓存没清就去换版本重装，往往把一个 OOM 问题绕成几天的环境工程。

四、逐条排查展开 ​

先用 batch 模式复跑，这是最重要也最便宜的一步。 把 GUI 里点过的操作落成一个 Tcl 脚本，用 vivado -mode batch -source build.tcl 跑：能稳定复现，说明与图形栈无关，问题在工程数据或工具核心；batch 不崩、只有 GUI 崩，方向立刻收窄到 libGL、显卡驱动或远程 X，构建链路可以先用 batch 保交付，不必停下手头进度。

137：先解决内存，再谈别的。 超大设计在 elaboration（精化）阶段就要把 parameter 算出的巨型数组、深层 generate 全部展开，内存峰值常出现在综合早期而不是布线期。dmesg 里的 OOM 行是铁证。应急可以加交换区争取存盘机会，正经做法是削减规模：巨型二维数组改成可推断 BRAM 的组织方式、拆分综合边界、避免 `define 宏参与递归式拼接。资源侧的规模评估见 Vivado LUT 利用率超限速查。

139：尾行就是二分坐标，逐 IP、逐 module 注释。 打开崩溃前最后处理的那个模块或 IP，先在 block design 里逐个移除 IP 重跑（IP 集成器的已知缺陷多数集中在特定 IP 的特定版本，背景见 Block Design 与 IP 集成器）；RTL 侧从顶层开始逐层注释例化，重点查自引用的宏和无终止条件的 generate。崩溃点随注释移动，就抓到了元凶。

清缓存是成本第二低的动作，注意只删可再生的产物。 Tcl 里先试温和手段：clean_ip_catalog 清理 IP 目录、reset_run synth_1 与 reset_run impl_1 复位运行结果；无效再关工程后删除工程下的 .Xil、.gen、*.bak、journal/log 锁文件以及用户级的 ~/.Xilinx/Vivado 缓存目录，重新打开让工具全部重生成。工程必须放在本地 SSD——NFS/网盘上的文件锁与缓存一致性是随机崩溃的经典来源。

崩溃包里有什么，提单前先自己看一眼。 vivado_pid*.zip 里通常含崩溃时刻的调用栈、环境信息与版本字符串，先确认栈顶停在综合、IP 生成还是图形模块——这决定了该二分 RTL 还是二分 IP。vivado.journal 是本次会话逐条执行过的 Tcl 命令流水，崩溃前最后一条成功命令与失败操作之间，就是最小复现脚本的取材范围；把这一段抽出来单独存成 repro.tcl，往往几十行就能在空工程里复现。

换小版本而非只换大版本，并查对应版本的 Answer Record。 同一年度线的补丁发布（如 2023.2 与 2023.2.1）修的就是这类崩溃，大版本升级反而可能引入 IP 兼容性问题。用相邻版本各跑一次最小用例：旧版不崩新版崩，先回退保进度，同时在 Xilinx 支持站按「崩溃阶段 + IP 名 + 版本号」检索对应版本的 Answer Record。版本与 IP 的长期管理见 IP 与版本管理。确属工具缺陷时，vivado_pid*.zip 崩溃包加最小复现工程是提单入场券。

五、预防与纪律 ​

  • 版本加补丁成对锁定：团队统一 Vivado 大版本加最新小补丁，IP 产物随锁定版本重新生成，不混用。
  • 工程只放本地盘：NFS/网盘只用于归档，工作副本放 SSD；IP 输出产物（生成的核、block design 产物）纳入版本管理，换机可直接复现。
  • CI 用 batch 跑冒烟：每次 RTL 变更在无界面环境跑一轮 synth_design 冒烟，GUI 图形栈问题和真实崩溃从此分开，崩溃也能在合入前暴露。
  • 宏与 generate 禁止自引用：code review 里把递归 `define、无界参数展开当检查项，巨型结构默认按 BRAM 推断来写。
  • 崩溃现场先归档再清理：退出码、vivado.log/.journal 尾行、vivado_pid*.zip、dmesg OOM 记录留齐，再决定清缓存还是提单。

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

本篇是 FPGA 工具报错排错簇中「Vivado 进程崩溃」节点的 FAQ 页：RTL 解析侧的报错见 Vivado module 找不到速查，设计规模导致的资源异常见 Vivado LUT 利用率超限速查，崩溃常发的 IP 集成环节见 Block Design 与 IP 集成器，避免版本踩坑的长期做法见 IP 与版本管理，更多中间层主题见 FPGA intermediate 目录。

一句话总结 ​

Vivado 段错误/崩溃先用 vivado -mode batch 复跑并看退出码：137 加 dmesg OOM 行是内存耗尽被杀，去削减 parameter 展开与超大结构、降规模；139 才是工具自身崩，按 vivado.log 尾行逐 IP、逐 module 二分出最小用例，再 clean_ip_catalog/reset_run 加删 .Xil、.gen 缓存，工程从网盘迁本地 SSD；GUI 独崩查 libGL/X11 图形栈，同脚本各版本都崩就换同年度线补丁版本并查对应 Answer Record，带 vivado_pid*.zip 崩溃包提单；防复发靠版本补丁锁定、IP 产物入版本管理与 CI batch 冒烟。