Repository navigation
Preflight privacy-protected inputs before xctrace launches #867
Description
Finding
On macOS 26.5.1 with Xcode 26.6, an xctrace --launch target could initialize its Metal backends but then make no progress opening a 638 MiB GGUF under ~/Desktop. A live process sample showed 100% of main-thread samples blocked in gguf_init_from_file -> fopen -> open$NOCANCEL. The same immutable inode, exposed through a hard link in /private/tmp and verified by SHA-256, loaded immediately and produced a valid GPU trace.
Why this matters
A profiling harness can misdiagnose the stall as model loading, GPU instrumentation, shader compilation, or a timeout. Extending the time limit does not help and leaves orphaned targets blocked in the protected-path open.
Generalizable improvement
Before launching a macOS profiler, classify every required input path against privacy-protected locations such as Desktop/Documents/Downloads. Either fail early with an actionable diagnostic or stage a verified read-only copy/hard link in a task-owned non-protected directory. Record the original and staged hashes in benchmark provenance, refuse mismatches, and always terminate/clean task-owned targets and links. A launch-progress marker after input open can distinguish this class from slow GPU work.
Activity
jxsl13 commentedon Sep 12, 2026
The fail-early input-preflight implementation is merged in #1007 at
6c4ec32ba8f918cc4df31e60f663334ee45e5f66, after all 14 PR CI jobs passed. Post-merge verification is running at https://github.com/jxsl13/perfscan/actions/runs/34698108171.The collector requires an explicitly audited inventory, automatically includes the resolved workload executable, classifies all paths before content reads, rejects known protected/unsupported locations, records actual bounded availability/hash observations, and requires an ordered post-input-open progress marker. It does not stage files, create links, change permissions, or treat parent availability as proof of profiler-child access. The native supported scope is local APFS on Darwin, with conservative policy exclusions rather than an exhaustive TCC model.
Keeping this issue open for its remaining explicit acceptance requirement: reliably terminate/clean task-owned profiler targets. Current command cancellation kills the direct recorder child; it does not establish cleanup of every launched descendant or service-launched target, and the documentation currently requires external target supervision. That boundary must be implemented and validated before claiming this whole issue is fixed. Original inputs and retained diagnostic artifacts must remain untouched.
jxsl13 commentedon Sep 12, 2026
The bounded direct-executable supervision path is now merged in PR #1010 as
6c960be88cc052a62e9da5b46d8f1d986b21ff56. All 14 PR checks and all 14 merged-main checks passed. The earlier #1007 input-preflight main run also completed successfully.For the explicitly acknowledged Darwin Time Profiler/direct-executable scope, the supervisor owns the exact suspended target and recorder, waits for attachment readiness before resuming the target, and performs bounded cancellation/cleanup with recorded reap outcomes. Retained native success and SIGTERM-cancellation runs validated that supported path; malformed, incomplete, forced-cleanup or mismatched evidence is rejected. Existing input inventories, source/hash observations and post-input-open progress markers remain required. No staging links, TCC changes, name-based process killing or launch fallback were added.
This does not establish cleanup of arbitrary descendants or service-launched targets, nor universal cleanup after uncatchable supervisor termination or kernel stalls. Unsupported launch/template scopes still require separate supervision; the direct-executable result is not a proof for them. Keeping #867 open for that remaining broader lifecycle requirement rather than claiming the bounded path closes the entire issue. Original inputs and retained diagnostic evidence are preserved.