Repository navigation
crash gate: a debug socket that never answers samples the app's main thread - #32239
Conversation
…thread and checks the moved socket Since at least 2026-11-01 03:14Z the CI crash gate fails on owned minis with "the app's debug socket never answered ... absent, alive=True" after 180 s, while the same commits pass on Blacksmith macOS (and one owned-mini run passed, answering after 31 s). The message said only that the /tmp link was absent. It now also says whether the socket in the state folder exists (the /tmp path is only a link to it), and samples the still-running app for 2 s: the whole report goes to the out folder (no-socket-<kind>.txt, uploaded with the gate's artifact) and the main thread's call graph is printed under the FAIL line, so the next red names the wait or the block that kept the control socket closed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-9124da39adbff74677d9
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Shipped in:
|
teamleaderleo
left a comment
There was a problem hiding this comment.
Review (claude-opus-5-5): SHIP at 5aee5c1
Review (subagent claude-opus-5-5): SHIP at 5aee5c1
The no-socket branch still returns a failure string (it only adds detail), so it cannot turn red into green; the moved path matches ControlSocketPath's tagged-debug row, a missing or unparseable sample gives an empty stack and drops the section, and the finally kill plus teardown.end() still run.
Follow-ups: [follow-up] sample() (existing helper) lets subprocess.TimeoutExpired (60 s) propagate; the run still ends red with teardown, but the FAIL line and later kinds are lost. Catching it in sample() would keep the message.
When the debug socket never answers, the crash gate now says why: it samples the app's main thread and checks the socket in the app's state folder.
Base-red-job: cmux-next / cmux-next crash ends the app
What the red is
Every red run of the
Crash ends the appstep (cmux-scheme-compile) ends both launches with:The app's own output is only
cmux: open-file limit 10240 -> 65536.It follows the runner, not a commit
The suspected range (
9e1c48fa22..e573965d34, including #28295 and #31904) is not the cause. The same failure shows up on owned minis hours before that range, and the same tips pass on Blacksmith macOS:Which commit looked like the first failure depended on whether that run's scheme compile landed on Blacksmith or on an owned mini. (#31600 keeps the landing DEV compile off Blacksmith macOS, which may be why owned minis now take more of these runs; I haven't verified that.)
The control socket opens only after
settings.waitForLoad(atLeast: 1), the boundedlaunchSettle.settled(within: 4 s)and the classic-settings migrations (AppDelegate.startSettingsAndControl). On owned minis something there, or a blocked main thread, takes more than 180 s; the one passing owned run took 31 s. The log can't tell which.This change
scripts/cmux-next/crash-ends-app-gate.py, on a socket that never answered:~/.local/state/cmux/cmux-debug-<tag>.sock, the real socket. The/tmppath is only its compatibility link, so an absent link alone doesn't show whether a listener exists.no-socket-<kind>.txtin the gate's out folder (already uploaded as thecmux-next-crash-gate-*artifact), and prints the main thread's call graph under the FAIL line.The verdict is unchanged: still red. With the next red on an owned mini, the cause will be in the log.
Checks:
py_compile;main_thread()tried on a syntheticsamplereport;scripts/cmux-next/prepush-gate.pyreports no new violations.Agent session: agent session
🤖 Generated with Claude Code
Summary by cubic
Improves the crash gate's failure report when the app's debug socket never answers, so the next red run names what kept the socket closed instead of only reporting an absent
/tmplink. The gate verdict is unchanged: it still fails.~/.local/state/cmux/cmux-debug-<tag>.sock), since the/tmppath is only a compatibility link to it.no-socket-<kind>.txt, and prints the main thread's call graph under the FAIL line.Written for commit 5aee5c1. Summary will update on new commits.