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
- 崩潰點在
Electron Framework 二進制內部,用戶可觸達的配置/文件根本到不了這裡
- 4/4 完全可復現,崩潰時間 79–85s (σ < 5s),與用戶輸入/操作/文件內容無統計相關
- 崩潰發生在主進程 ↔ renderer 的 IPC stream 通信路徑 (uv__io_poll → LibuvStreamWrap::OnUvRead → CallJSOnreadMethod),不是用戶 JS 代碼
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_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 / 提交前确认
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% 可復現。
環境
com.minimax.agent.cn284XR4YSQ4)/usr/local/bin/node(官方 pkg),全局僅裝@google/gemini-cli與mmx-cli,無異常 PATH 掛鉤4 次崩潰 incident 清單(按時間)
AB3D0297-026C-4351-B84F-E1F88D760BFF0x1107ffea8D2718721-8EAC-48DB-9909-152789217C780x113b03ea8B0818CDB-5941-4855-B590-BFA57041626B0x1146dfea8B13F2B50-5080-4392-B787-08419D6EA0CC0x10ff8fea84 份完整
.ips文件已隨本 issue 附件上傳。崩潰共同特徵(4 次完全一致)
EXC_BREAKPOINT(SIGTRAP, code 5)Electron Framework二進制內部,棧頂符號ares_dns_rr_get_ttl + 3609364Steps to reproduce / 复现步骤
為什麼這是用戶層面無法解決的 bug
Electron Framework二進制內部,用戶可觸達的配置/文件根本到不了這裡ares_dns_rr_get_ttl + 3609364偏移 ≈ 3.5MB,實際崩潰發生在該符號附近被靜態鏈接進同一二進制的 V8/Electron 內聯代碼段,符號表無法進一步定位副作用(值得一併修)
每次崩潰會清空當前項目工作目錄 —
~/.minimax-agent-cn/projects/<project>/內的內容被清空,用戶業務數據需從
*.backup-YYYYMMDD-HHMMSS目錄手動恢復。建議在 IPC stream 異常時走 graceful degradation 路徑,而不是直接 SIGTRAP 殺進程,
否則每次崩潰都會伴隨用戶數據丟失。
同版本同期 bug(疑似同源)
.opencode文件夾的時候,模型無法響應v3.0.43 似乎是一個普遍有問題的版本,建議評估回滾。
建議排查方向
uv__io_poll與v8::MicrotasksScope交互時的 isolate 鎖可提供
如有需要我可提供
sysdiagnose或運行你們 push 的 debug build。Expected behavior / 预期行为
/
Actual behavior / 实际行为
crash.zip
Logs, screenshots, or crash reports / 日志、截图或崩溃信息
Before submitting / 提交前确认