Skip to content

[Bug]: Mac v3.0.43 啟動後約 80 秒必崩潰 (EXC_BREAKPOINT in Electron Framework) — 4 次完全可復現 #60

@sueieche

Description

@sueieche

Version / 版本号

3.0.43 (build 3.0.43.63)

Platform / 平台

macOS

OS version / 系统版本

macOS 15.5 (24F74), MacBookPro18,2 (Apple Silicon, M1 Max)

Issue area / 问题类型

Startup / install / update

Upload ID / 日志上传 ID

cannot upload app 崩潰在 startup 之後 ~80 秒,根本來不及進 Settings 上傳日誌

What happened? / 问题描述

問題

MiniMax Code 3.0.43 (build 3.0.43.63) 在 macOS 15.5 / Apple Silicon 上啟動後
穩定在 79–85 秒內崩潰,崩潰時無任何錯誤彈窗,直接退出。

從 00:57 到 01:39 的 1 小時 42 分鐘內連續崩潰 4 次,全部 100% 可復現。

環境

  • App: MiniMax Code 3.0.43 (build 3.0.43.63)
  • Bundle ID: com.minimax.agent.cn
  • OS: macOS 15.5 (24F74)
  • Hardware: MacBookPro18,2 (Apple Silicon, M1 Max)
  • Code signing: 有效 (Team 284XR4YSQ4)
  • Node 環境: v24.16.0 at /usr/local/bin/node(官方 pkg),全局僅裝
    @google/gemini-climmx-cli,無異常 PATH 掛鉤
  • 用戶環境: 標準 Homebrew + 默認 shell,未做任何定製

4 次崩潰 incident 清單(按時間)

# incident_id 時間 (CST) PC 距啟動
1 AB3D0297-026C-4351-B84F-E1F88D760BFF 00:57:56 0x1107ffea8 9 s
2 D2718721-8EAC-48DB-9909-152789217C78 01:05:07 0x113b03ea8 85 s
3 B0818CDB-5941-4855-B590-BFA57041626B 01:08:24 0x1146dfea8 84 s
4 B13F2B50-5080-4392-B787-08419D6EA0CC 01:39:10 0x10ff8fea8 79 s

4 份完整 .ips 文件已隨本 issue 附件上傳。

崩潰共同特徵(4 次完全一致)

  • 異常類型: EXC_BREAKPOINT (SIGTRAP, code 5)
  • 崩潰線程: Thread 0(主進程)
  • 崩潰位置: Electron Framework 二進制內部,棧頂符號
    ares_dns_rr_get_ttl + 3609364
    • 4 次偏移完全相同 → 同一條指令處崩潰
    • PC 地址絕對值浮動 ±60KB → 來自 macOS ASLR,並非不同崩潰點
  • 崩潰路徑(棧底到棧頂):

Steps to reproduce / 复现步骤

為什麼這是用戶層面無法解決的 bug

  1. 崩潰點在 Electron Framework 二進制內部,用戶可觸達的配置/文件根本到不了這裡
  2. 4/4 完全可復現,崩潰時間 79–85s (σ < 5s),與用戶輸入/操作/文件內容無統計相關
  3. 崩潰發生在主進程 ↔ renderer 的 IPC stream 通信路徑 (uv__io_poll → LibuvStreamWrap::OnUvRead → CallJSOnreadMethod),不是用戶 JS 代碼
  4. ares_dns_rr_get_ttl + 3609364 偏移 ≈ 3.5MB,實際崩潰發生在該符號附近被靜態鏈接進同一二進制的 V8/Electron 內聯代碼段,符號表無法進一步定位

副作用(值得一併修)

每次崩潰會清空當前項目工作目錄
~/.minimax-agent-cn/projects/<project>/ 內的內容被清空,
用戶業務數據需從 *.backup-YYYYMMDD-HHMMSS 目錄手動恢復。
建議在 IPC stream 異常時走 graceful degradation 路徑,而不是直接 SIGTRAP 殺進程,
否則每次崩潰都會伴隨用戶數據丟失。

同版本同期 bug(疑似同源)

建議排查方向

  • v3.0.43 對 Node stream / IPC 通道 的改動,重點關注
    uv__io_pollv8::MicrotasksScope 交互時的 isolate 鎖
  • c-ares 靜態鏈接段附近的內存佈局變化
  • 主進程 startup 後 60–90 秒內觸發的某個後台計時器 / 健康檢查
  • 修復前加 startup race-guard,讓 IPC 異常不直接殺進程

可提供

如有需要我可提供 sysdiagnose 或運行你們 push 的 debug build。

Expected behavior / 预期行为

/

Actual behavior / 实际行为

crash.zip

Logs, screenshots, or crash reports / 日志、截图或崩溃信息

Before submitting / 提交前确认

  • I have searched existing issues.
  • I am using the latest version available to me.
  • I have removed sensitive information from logs/screenshots.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions