Skip to content

Firebase Unity SDK – Native crash in Realtime Database (uS WebSocket thread) #1391

Open

Description

@darren-beckett

Firebase Unity SDK – Native crash in Realtime Database (uS WebSocket thread)

Summary

Unity Editor crashes with a native crash in FirebaseCppApp-13_7_0.dll (Windows) when using Firebase Realtime Database with multiple ValueChanged and ChildAdded/ChildRemoved listeners. The crash occurs on a worker thread in the uS (µWebSockets) layer, not in C#.

Environment

  • Unity: 6000.3.0f1 (Unity 6)
  • Firebase Unity SDK: 13.7.0 (Realtime Database)
  • Platform: Windows 10 (64-bit), Unity Editor
  • Scripting: .NET / Mono

Crash details

  • Module: FirebaseCppApp-13_7_0.dll
  • Thread: Worker thread (stack shows BaseThreadInitThunk / RtlUserThreadStart)
  • Native stack (representative frames):
    • uS::TLS::Context::operator bool
    • uS::Node::...
    • uS::Socket::write
    • uS::Socket::freeMessage

So the failure is in the C++ WebSocket/TLS code, not in managed code.

Reproduction

  1. Open a Unity project with Firebase Realtime Database (SDK 13.7.0).
  2. Load a games list from the database and build UI for each game.
  3. For each game, attach:
    • DatabaseReference.ValueChanged
    • DatabaseReference.ChildAdded (e.g. on a /Players child ref)
    • DatabaseReference.ChildRemoved
  4. Trigger a “refresh” that:
    • Removes all listeners,
    • Fetches a new snapshot (GetValueAsync / equivalent),
    • Rebuilds the UI,
    • Re-attaches the same listeners for each game (either in one frame or over a few frames).
  5. The crash can occur during or shortly after re-attaching many listeners, or when many ValueChanged callbacks are processed. It is intermittent but reproducible under load.

Mitigations tried (C# side)

  • Coalescing UI rebuilds to at most one per frame.
  • Not attaching listeners while a “refresh” is in progress.
  • Deferring listener attachment by one frame after the UI rebuild.
  • Staggering listener attachment (e.g. 5 games per frame).
  • Delaying the single coalesced UI rebuild by one frame.
  • In Editor only: adding an extra 2.5 s delay after the UI rebuild before starting listener attachment.

These reduce frequency but do not eliminate the crash; the failure remains in native code.

Request

Please check whether this uS WebSocket/TLS path is subject to known race conditions or use-after-free when many listeners are added/removed or when many callbacks are delivered, and whether a fix or workaround is available or planned for the Unity SDK.

Activity

  1. CrowSoda commented on Jul 9, 2026

    @CrowSoda

    Root-caused this on the C++ side. The uS::Socket::write / uS::Socket::freeMessage frames are a symbolication artifact: the DLL barely exports any RTDB desktop code, so the crash reporter snaps unexported addresses to the nearest named uS:: export. The real fault is a dangling const View* in WebSocketListenResponse (database/src/desktop/core/web_socket_listen_provider.cc). Detach a listener while a listen response is in flight and the callback reads a View the SyncTree already freed. Connection flaps make the window big, which is why this clusters around reconnects.

    Full analysis with disassembly, minidump evidence, and a proposed one-line fix: firebase/firebase-cpp-sdk#1881. That file is unchanged from 12.x through current main, which matches this reproducing on 13.7.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions