Antigravity Electron39 崩溃排查与修复全记录

作者：wzerovk | 发布时间： | 更新时间：

Antigravity Electron39 崩溃排查与修复全记录

谷糕 antigravity从刚出就开始用了，刚出的时候配合学生订阅疯狂白嫖，帮我做完了一整个R的生信项目，效果很好，但是不知道从哪个弱智版本开始，electron就开始崩溃，倒是也几乎不影响你正常使用，但是通知疯狂报崩溃真的很几把恶心，在网上也没有找到好的解决方案，无非是禁用sandbox和gpu加速，实际上也不好使，想着干脆算了，等更新吧，等到年后了问题依旧，今天掏一上午来跟这个干上了，所幸解决了，AI真强啊，好时代来临力（喜

环境信息

  • OS: Arch Linux 6.19.11-zen1-1-zen

  • GPU: NVIDIA 4060 Laptop (驱动 580.142)

  • 软件: antigravity 1.19.6-1 (pacman), 使用 electron39

  • 现象: antigravity 频繁崩溃 (SIGSEGV / SIGTRAP)

排查思路

第一阶段：定位崩溃来源（错误方向）

假设: Electron 在 Linux 上的 GPU 加速/沙箱与 NVIDIA 驱动不兼容（这是最常见的 Electron 崩溃原因）

操作:

  1. coredumpctl list — 查看崩溃记录，确认是 electron39 进程

  2. 读取 /usr/bin/antigravity 启动脚本，发现它会读取 ~/.config/electron39-flags.conf

  3. 依次尝试:--disable-gpu-sandbox → 仍然崩溃

  4. --disable-gpu + --no-sandbox → 仍然崩溃

关键观察: --no-sandbox 生效了（崩溃命令行里 --enable-sandbox 消失了），但进程还是 SIGSEGV。说明不是 GPU/沙箱问题，假设被证伪。

第二阶段：从 coredump 精确定位崩溃模块（正确方向）

核心思路: coredump 里有完整的内存映射，可以把崩溃的虚拟地址映射回具体的 .so/.node 文件

步骤 1: 获取崩溃地址

从 coredumpctl info 输出中:

Stack trace of thread 277673:
#0  0x00007fed67594775 n/a (n/a + 0x0)

崩溃地址是 0x00007fed67594775，但符号缺失（n/a），无法直接知道是哪个函数。

步骤 2: 获取内存映射表

coredumpctl debug <PID>  # 进入 gdb
(gdb) info proc mappings

这会输出进程中所有加载的共享库及其虚拟地址范围，例如:

0x00007fed67554000 0x00007fed67571000  .../watcher.node
0x00007fed67571000 0x00007fed675bf000  .../watcher.node
0x00007fed675bf000 0x00007fed675cc000  .../watcher.node
0x00007fed675cc000 0x00007fed675ce000  .../watcher.node
0x00007fed675ce000 0x00007fed675d0000  .../watcher.node

步骤 3: 匹配地址到文件

崩溃地址 0x7fed67594775 落在 0x7fed67554000 - 0x7fed675ce000 区间内，对应文件:

/usr/lib/antigravity/node_modules/@parcel/watcher/build/Release/watcher.node

而不是 electron39 本身！

步骤 4: 计算文件内偏移

偏移 = 崩溃地址 - 模块基址 = 0x7fed67594775 - 0x7fed67554000 = 0x40775

步骤 5: 用 nm 找到偏移对应的函数

nm watcher.node | sort | awk '{val=strtonum("0x"$1); if(val<=0x40775) last=$0; else {print last; exit}}'

结果:

00000000000406f0 W _ZNSt19_Sp_counted_deleterIP7DirTree14DirTreeDeleterSaIvELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv

Demangling: std::_Sp_counted_deleter::_M_dispose()

结论: @parcel/watcher 2.5.1 的 C++ 代码在释放 DirTree 对象时访问了无效内存，导致 SIGSEGV。这是该模块自身的 bug，与 Electron GPU/沙箱无关。

第三阶段：修复

方案: 用 npm 编译更新版本的 @parcel/watcher 替换掉有 bug 的 2.5.1

# 1. 安装 + 编译最新版
mkdir -p /tmp/parcel-watcher-rebuild && cd /tmp/parcel-watcher-rebuild
npm init -y
npm install @parcel/watcher                    # 下载源码
npx node-gyp rebuild --directory=node_modules/@parcel/watcher  # 编译

# 2. 备份 + 替换
sudo cp /usr/lib/antigravity/node_modules/@parcel/watcher/build/Release/watcher.node{,.bak}
sudo cp /tmp/parcel-watcher-rebuild/node_modules/@parcel/watcher/build/Release/watcher.node \
       /usr/lib/antigravity/node_modules/@parcel/watcher/build/Release/

# 3. 清理 electron flags（之前误加的）
rm ~/.config/electron39-flags.conf

N-API 模块 ABI 稳定，不受 Node 版本限制，可以安全用系统 node 编译后给 electron 使用。

关键学到的

  1. Electeron 崩溃 ≠ Electron 的锅: 崩溃进程名是 electron，但可能是它加载的任何 .so/.node 出的问题

  2. coredump + info proc mappings 是定位共享库崩溃的根本方法: 虚拟地址 → 地址范围 → 具体文件 → 偏移 → 符号表

  3. N-API (node_api) 模块可以跨 Node 版本使用: 不同于传统的 V8 Addon，N-API 模块 ABI 稳定

  4. GPU/沙箱是最常见原因，但这吊东西不是

修复后维护

  • 备份文件: /usr/lib/antigravity/node_modules/@parcel/watcher/build/Release/watcher.node.bak

  • 新编译文件: ~/Downloads/watcher.node

  • antigravity 更新后如果又崩溃，检查版本并替换:


标签：antigravity, electron