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

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-cli 與 mmx-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(疑似同源)

• #55 — 連續提問會衝擊之前的提問
• #56 — Mac 3.0.43 版回復中消息不會自動滾動
• #58 — 當存在 .opencode 文件夾的時候,模型無法響應
  v3.0.43 似乎是一個普遍有問題的版本,建議評估回滾。

建議排查方向

• v3.0.43 對 Node stream / IPC 通道 的改動,重點關注
  uv__io_poll 與 v8::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.

No source file or test is named. Start with the four attached .ips reports and the v3.0.43 startup path, focusing on the Node stream/IPC route around uv__io_poll and the 60–90 second background activity described here. Done means the reported macOS configuration no longer crashes and the project directory is not cleared.