Dear all,
I have encountered a crash similar to this every ~20mins. My system is also Apple Silicon which, it goes without saying, doesn't have 32bit support. I have a 2023 MBP with Apple M2 Pro CPU with macOS version 26.1.2 (Tahoe), Apple Silicon + Rosetta. TLDR; There probably isnt' a solution to this issue until Sky Go ships with an Apple Silicon binary installer. Sky dev team could give that a go. I can't attach the exception log because repeated numbers are banned.
Incident Identifier B25E5FE7-5CA3-460D-87BF-0FE3653217D8
The log points to a segmentation fault in the malloc zone during memory-pressure handling. Probably a heap corruption somewhere in Sky Go's Electron + native player stack, amplified by Rosetta and possibly tight memory on a new macOS build. ¯\_(ツ)_/¯
Exception:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000000000250b
Exception Codes: 0x0000000000000001, 0x000000000000250b
Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11
Terminating Process: exc handler [26372]
Here is what I think:
1. Sky Go is Intel-only and runs under Rosetta
Code Type: X86-64 (Translated) and "translated": true mean the app is x86_64 and is being emulated on my M2 Pro. That adds overhead and can surface bugs that don't show up on Intel Macs.
2. Crash type: bad memory access during malloc “pressure relief”
The crashing thread is com.apple.libdispatch-manager, inside:
szone_pressure_relief → malloc_zone_pressure_relief → malloc_memory_event_handler
So the process didn't die in “normal” app code on that thread—it died while the system allocator was reacting to memory pressure. Failures there are very often heap corruption (something in the app or a bundled library wrote past a buffer, double-freed, or corrupted allocator metadata). The fault address 0x250b is essentially NULL + small offset, which fits use of a bad/corrupted pointer, not a random hardware glitch.
3. What’s actually in the app
The loaded images match an Electron shell (Electron Framework 22.3.16), plus Sky’s native pieces (skygoplayerx, libPCShowServer.dylib), GStreamer 0.10 (quite old), FFI/native addons (ffi_bindings.node, keystore.node). Many threads are inside libPCShowServer.dylib (playback/DRM pipeline). So the bug is likely in that native stack or interaction with Electron/Chromium under memory pressure.
4. Rosetta vs RIP
RIP register does not match crashing frame is a known kind of noise with translated processes; it doesn’t change the main story (bad access in allocator/pressure path). Could be renamed to something nicer.
5. Environment
I'm on macOS Tahoe 26.4 with multiple displays (built-in + two Dells via a dock). Heavy GPU/graphics work and large VM regions are consistent with a Chromium + video app which leads to memory pressure.
