macOS: MallocStackLogging warning persists in v1.0.80 #4614

Activity

1. github-actions

   added

   triage

   on Aug 26, 2026
2. DavidTeju commented on Aug 28, 2026

   

   DavidTeju

   on Aug 28, 2026

   More actions

   [From Femi's agent: GPT-5.6 Sol]

   I reproduced this on an actual signed 1.0.79 session and then isolated a deterministic trigger. This does not appear to be a 1.0.80 regression or something that happens on every tool call.

   Verified version range

   Version	Result when the macOS MSL-disable callback fires
   1.0.68	warning rendered inside TUI
   1.0.77	warning rendered inside TUI
   1.0.79 / 1.0.79-9	warning rendered inside TUI
   1.0.80	warning rendered inside TUI
   1.0.81-0, -3, -4, -5, -9	warning rendered inside TUI
   1.0.81 stable	warning rendered inside TUI
   1.0.82-0	warning rendered inside TUI

   The naturally occurring case remains intermittent. Clean controls produced zero warnings from:

   • --version, mcp list, and plugins list across cached versions
   • 20 direct launches each of zsh, bash, Ruby, Python, and /usr/bin/true
   • an interactive bash tool call
   • sync and background task agents
   • an async Ruby shell command

   Isolated trigger

   Apple's public libmalloc source shows that malloc_memory_event_handler() dynamically loads MallocStackLogging.framework and forwards memory-status events to msl_handle_memory_event():

   • https://github.com/apple-oss-distributions/libmalloc/blob/c49dafa25f1efe8607701ae6014a663ad2ee437f/src/malloc.c#L3287-L3308
   • https://github.com/apple-oss-distributions/libmalloc/blob/c49dafa25f1efe8607701ae6014a663ad2ee437f/private/stack_logging.h#L102-L107

   MEMORYSTATUS_DISABLE_MSL is 0x80000000. Calling the framework handler with that event while stack logging is inactive deterministically emits the exact diagnostic:

   void *msl = dlopen(
       "/System/Library/PrivateFrameworks/MallocStackLogging.framework/MallocStackLogging",
       RTLD_NOW);
   void (*handle_memory_event)(unsigned long) =
       dlsym(msl, "msl_handle_memory_event");
   handle_memory_event(0x80000000UL);

   repro(<pid>) MallocStackLogging: can't turn off malloc stack logging because it was not enabled.
   

   I injected that same callback after startup into each published Copilot TUI package listed above (using its matching app.js and native modules under an injectable Node host). Every version wrote one diagnostic directly into the alternate-screen UI.

   I also scanned the signed launcher and matching native modules for every tested version:

   turn_off_stack_logging imports:       0
   turn_off_stack_logging lookup strings: 0
   

   The MallocStackLogging strings inside runtime.node are environment-variable names; the diagnostic text and turn_off_stack_logging symbol/name are absent. I therefore could not substantiate the direct native-addon call asserted in #4375.

   Conclusion

   The underlying diagnostic is emitted by macOS when an MSL-disable memory-status event reaches a process where MSL was not enabled. The Copilot-specific bug is that an asynchronous native write to file descriptor 2 escapes into and corrupts the TUI. This also explains reports from unrelated long-running processes such as Ruby, Codex, and k9s.

   A robust CLI-side fix would route process-level stderr through the logger/TUI renderer (or narrowly suppress this known harmless diagnostic) so asynchronous native diagnostics cannot draw directly into the alternate screen.

   Environment: macOS 15.7.4 (24G517), arm64, iTerm2 3.6.11; MallocStackLogging, MallocStackLoggingNoCompact, MallocNanoZone, and DYLD_INSERT_LIBRARIES all unset in the natural occurrence.
3. 1fanwang commented on Sep 8, 2026

   

   1fanwang

   on Sep 8, 2026

   More actions

   Still present on 1.0.83, so the version table above extends one more release.

   copilot(<pid>) MallocStackLogging: can't turn off malloc stack logging because it was not enabled.
   

   One detail that supports the conclusion in the comment above about the write escaping the renderer. On the same machine where this appears in the TUI, the string is absent from every log file, including runs started with --log-level debug --log-dir, and it is absent from the session transcript in events.jsonl. Nothing that passes through the logger ever sees it, which is consistent with an asynchronous native write going straight to file descriptor 2 while the alternate screen is active. It also means an affected user cannot produce a captured artifact for a bug report, only a screenshot.

   Environment: Copilot CLI 1.0.83, macOS 26.6.2 (25G83), arm64, installed at /usr/local/bin/copilot. MallocStackLogging, MallocNanoZone, and DYLD_INSERT_LIBRARIES all unset.

   👍React with 👍2Reacted by Emil Müller and Brian Exelbierd
4. tpope

   closed this as completedon Oct 11, 2026
5. github-actions

   removed

   triage

   on Oct 11, 2026