Skip to content

[macOS] ClipCascade crashes after connecting to peers on macOS 27 #178

Closed
Closed
[macOS] ClipCascade crashes after connecting to peers on macOS 27#178

Description

@breellz
breellz
opened on Sep 20, 2026

Describe the bug

On macOS 27.0 on Apple Silicon, the macOS desktop client connects to Android peers and then crashes. The menu-bar icon disappears and clipboard synchronization stops. The crash report shows SIGTRAP in -[NSStatusItem setMenu:] via pystray while a background stats thread updates the tray menu.

Steps to reproduce

  1. Install the Apple Silicon macOS build.
  2. Sign in and connect Android peers.
  3. Wait for the peer-count/menu update.

Expected behavior

The macOS client remains running and synchronizes clipboard content with connected Android devices.

Actual behavior

The app crashes after the peers connect, leaving no usable menu-bar item and no Mac clipboard synchronization.

Environment

  • macOS 27.0 (26A428)
  • Apple Silicon
  • ClipCascade macOS desktop release
  • Android Pixel phone and tablet connected

Activity

  1. mjwyatt2 commented on Sep 26, 2026

    @mjwyatt2
    mjwyatt2
    on Sep 26, 2026

    Additional report of frequent ClipCascade desktop crashes on macOS 27:

    • Affected: Mac mini, Apple Silicon, macOS 27.0 (26A428).
    • Desktop client: official ARM 3.2.0 release; installed bundle files were compared with the official download and match.
    • Comparison: ClipCascade works as expected on my MacBook Pro running macOS 26.7. Its client version/settings have not yet been independently compared.
    • Symptom: desktop client exits and requires manual relaunch; the local Java server remains running.
    • Review of 26 local ClipCascade crash reports from September 19–25 found 12 with this leading stack:
    -[BSServiceMainRunLoopQueue assertBarrierOnQueue]
-[FBSScene _updateClientSettings:]
-[FBSScene updateClientSettingsWithBlock:]
...
-[NSSceneStatusItem _updateSupportsExpandedInterfaceSession]
-[NSStatusBarButtonCell setStatusMenu:]
-[NSStatusBarButton setStatusMenu:]

    Some other reports show a short launcher stack ending in raise/SIGTRAP; these may accompany the same failure and should not be counted as separate incidents. Two reports show an invalid memory free involving CoreGraphics; one proceeds through AppKit/QuartzCore UI cleanup. These signatures do not establish a hardware defect or prove that all crashes share one cause.

    During monitoring on September 25, the client logged a successful WebSocket connection at 09:59 EDT, and macOS recorded a SIGTRAP crash at 11:02:30 EDT. The Java server remained running. The client log did not record the crash. Nearby network snapshots showed the interface reachable, but they were periodic snapshots, not a continuous connectivity trace.

    Does this match the menu-update threading issue described here, and is there a patch or test build that dispatches these updates onto the macOS main thread?

    A local sysdiagnose and crash reports are available for targeted, redacted follow-up. The full sysdiagnose has not been uploaded.

  2. Sathvik-Rao commented on Oct 25, 2026

    @Sathvik-Rao
    Sathvik-Rao
    on Oct 25, 2026
    Owner

    #182

  3. Sathvik-Rao
    closed this as completedon Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions