Quartus 崩溃/段错误速查：Internal Error 与闪退怎么办
更新时间：2026-10-23。FAQ 速查页，属于 FPGA 工具报错排错系列。Quartus 崩溃的麻烦在于表现形式太多：
quartus_map跑到一半直接退出、GUI 窗口凭空消失、日志里只有一句Internal Error: Sub-system: ...或者干脆一行Segmentation fault (core dumped)。排查的关键是先分清——崩在哪个子系统、进程是自己崩的还是被系统杀的，两条路走向完全不同的病因。同系列的 RTL 解析侧报错见 Quartus 找不到模块速查，AMD 侧同类问题见 Vivado 段错误/崩溃速查。
本文要回答的问题
Internal Error: Sub-system: FPP/PTI/CDB...里的子系统名说明了什么？- 段错误（SIGSEGV）和内存耗尽被杀怎么快速区分？
- 删
db、simulation_db为什么能解决一大半「莫名崩溃」？ - 怀疑是 Quartus 软件本身的 bug，怎么最小化复现并查 known issue？
- 崩溃现场要收集哪些文件，报给 Intel/Altera 才有用？
一、报错原文与现象
1. 命令行流程中途崩溃的典型输出：子系统名就是第一坐标。
Info (293000): Quartus Prime Fitter was unsuccessful. 0 errors, 1 warning
Error: Quartus Prime Fitter was unsuccessful. 1 error, 1 warning
*** Fatal Error: Segment Violation at (nil)
Module: quartus_fit
Stack Trace:
0x5f3a21: FITCC_EXPERT + 0x1a21
End-trace2. Internal Error 的标准横幅：前两个字段决定去哪查。
Internal Error: Sub-system: FPP, File: /quartus/fitter/fpp/fpp_place.cpp, Line: 4821
Detected at: 2026.10.23 09:41:07
Version: 22.1std.0 Build 9153. GUI 直接消失时，shell 拿到的退出码是铁证。
quartus_sh --flow compile top
echo $?
# 139 = 128+11 SIGSEGV 段错误，Quartus 进程自身访问了非法地址
# 137 = 128+9 SIGKILL，绝大多数是内存耗尽被 OOM killer 杀的Sub-system 字段给出崩溃模块（FPP 布局、PTI 时序、CDB 编译数据库、QEXE 执行框架），File/Line 是源码位置——这两样凑齐，去 Intel 知识库按原文检索命中率极高。退出码 137 配合 dmesg | tail 里的 Out of memory: Killed process ... (quartus_fit) 则是 OOM，与工具自身崩溃无关。
二、现象 → 病因 → 处置速查表
| 现象 | 最常见病因 | 处置 |
|---|---|---|
| 退出码 137，dmesg 有 OOM 行 | 超大设计在 map/fit 阶段撑爆内存，虚拟机或容器内存上限太小 | 加内存或提高 cgroup 限额；降编译并行度、拆分分区、关增量编译省峰值 |
| 139 或 Internal Error 固定停在同一子系统 | 该版本该模块已知缺陷 | 查 Intel knowledge base 按 Sub-system + File 名 检索 known issue，换同版本线补丁验证 |
| 换机器/换版本后开始崩，旧工程直接打开 | db、simulation_db 增量缓存与当前版本不兼容或已损坏 | 关工程后删 db、simulation_db、incremental_db 全量重编 |
崩前刚手工编辑过 .qsf 或 .qpf | 工程文件损坏：冲突的 assignment、非法字符、半截写入 | 用版本管理回退 .qsf；或新建空工程逐个 re-import 源文件 |
| 崩在生成/例化某个 IP 或 Platform Designer 系统时 | IP 生成器（Qsys/PD）或该 IP 版本缺陷 | 重新 generate IP；升级该 IP；逐个禁用 IP 二分定位 |
| 虚拟机里编译大设计随机崩、小工程正常 | 虚拟化内存上限加 balloon 回收，峰值时被杀 | 提高 VM 内存、锁定 balloon；大设计迁物理机或加 swap |
| 极小空工程也崩、任何操作都崩 | 安装损坏或用户配置目录（~/.altera.quartus）损坏 | 删用户配置目录重开；校验安装完整性或重装同补丁版本 |
| 最小化用例后各版本各机器都崩 | 确属 Quartus 软件 bug | 收集崩溃日志与最小工程，走 Intel 支持渠道提单 |
三、排查决策流程
分诊顺序：先看退出码分通道，再按子系统名查 known issue，最后删缓存与最小化复现。图中颜色含义：红=崩溃入口，蓝=排查动作，绿=验证通过，橙=修复动作，紫=防复发。
读这张图抓住主线：红色入口之后先按退出码分流——137 走内存通道，139 才进入工具自身崩溃通道；橙色修复每做一步都要回到绿色「全量重编通过」节点验证，不通过就继续沿二分路径下沉。 顺序别反：不删 db 缓存就先重装软件，经常把一个缓存损坏问题绕成几天的环境工程。
四、逐条排查展开
先分清「自己崩」还是「被杀」。 batch 流程崩了先 echo $?：137 去 dmesg 或 journalctl -k 找 OOM 行，方向立刻收窄到内存——虚拟机和容器场景尤其高发，宿主给的限额看着够，fit 阶段峰值一来照样被杀，提高 cgroup/VM 限额或加 swap 是最便宜的验证。139 才是 Quartus 自身段错误，进入下一步。
Internal Error 横幅按原文检索，别翻译。 Sub-system 加 File 字段（如 FPP + fpp_place.cpp）原样贴进 Intel/Altera knowledge base 搜索，已知缺陷的条目通常带受影响版本与修复补丁号。查到就直接换同版本线的补丁版（如 22.1std.0 → 22.1std.2）验证，比跨大版本升级风险小得多。
GUI 闪退但命令行不崩，问题多半在图形栈而非编译核心。 同一份工程用 quartus_sh --flow compile top 在终端能跑完、只有双击打开 GUI 才消失，方向就收窄到显卡驱动、Qt 库或远程桌面环境：先用命令行流程保住交付，再回头升级驱动或换本地会话验证，不必停下手头进度。
删 db 缓存是成本最低的修复，命中率高。 工程目录下的 db、simulation_db、incremental_db 是增量编译的中间产物，版本切换、异常中断、跨机器拷贝后极易损坏，表现就是「好好的工程突然就崩、新开工程却正常」。关掉 Quartus 后删掉这三个目录全量重编，一大半「莫名崩溃」到此为止。注意只删可再生产物，源文件与 .qsf 不动。
.qsf 损坏排查靠回退与 diff。 崩前手工改过约束、脚本写入被中断、合并冲突留下的半截 assignment，都可能让 parser 直接崩。工程在版本管理里就先 git diff 看最近改动；没有版本管理就新建空工程，把源文件逐个 re-import 进去，崩在哪个文件上一目了然。模块解析类的报错（不是崩溃）走 Quartus 找不到模块速查 的口径。
最小化复现：逐个排除 IP 与源文件。 从顶层开始二分：先整体禁用一半 IP 或注释一半 module 例化，看崩溃点是否移动；移动就继续向嫌疑侧收，直到一个空工程加单个 IP/源文件就能复现。这个最小工程既是验证补丁的依据，也是提单的核心材料。AMD 侧同样的二分思路见 Vivado 段错误/崩溃速查。
崩溃现场收集三样东西再清理。 ① 崩溃时终端或消息窗口的完整输出（含 Sub-system、File、Line、Stack Trace）；② 工程目录下的崩溃转储与 .rpt 报告尾部（fit/map 各阶段最后处理对象就是复现坐标）；③ 版本字符串（Help → About 或 quartus_sh --version 输出，补丁号一个都不能省）。这三样加最小复现工程打包，报给 Intel 支持才不是「我用着用着就崩了」的空单。
五、防复发纪律
- 版本加补丁成对锁定：团队统一 Quartus 大版本加最新小补丁，IP 产物随锁定版本重新 generate，不混用。
.qsf进版本管理：约束文件一律走 git，手工改动有 diff 可查，损坏时一键回退。- 虚拟机给足内存并留 swap：大设计 fit 峰值按器件规模预留 1.5 倍余量，cgroup 限额宁高勿低。
- CI 里保留一次「干净重编」：定期删
db/simulation_db全量编译，缓存损坏类崩溃在本地爆发前先在 CI 暴露。 - 崩溃现场先归档再清理：退出码、Internal Error 原文、版本号、最小工程留档，再删缓存重装——否则提单时两手空空。
一句话总结
Quartus 崩溃/段错误先拿退出码分流：137 加 dmesg OOM 行是内存耗尽被杀，去提虚拟机/容器限额、降编译峰值；139 或 Internal Error 才是工具自身崩，按 Sub-system + File 原文查 Intel 知识库 known issue，删 db、simulation_db、incremental_db 全量重编，.qsf 靠版本管理回退 diff，仍崩就逐个排除 IP 与源文件做最小化复现、换同版本线补丁验证，确属软件 bug 带崩溃日志、版本号与最小工程提单；防复发靠版本补丁锁定、.qsf 入库与 CI 定期干净重编。