You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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#.
So the failure is in the C++ WebSocket/TLS code, not in managed code.
Reproduction
Open a Unity project with Firebase Realtime Database (SDK 13.7.0).
Load a games list from the database and build UI for each game.
For each game, attach:
DatabaseReference.ValueChanged
DatabaseReference.ChildAdded (e.g. on a /Players child ref)
DatabaseReference.ChildRemoved
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).
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.
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.
Activity
feat(database): Add reproduction project for Issue #1391
feat(database): Add reproduction project for Issue #1391
fix: remove automated test dependency and enhance repro with backgrou…
CrowSoda commentedon Jul 9, 2026
Root-caused this on the C++ side. The
uS::Socket::write/uS::Socket::freeMessageframes are a symbolication artifact: the DLL barely exports any RTDB desktop code, so the crash reporter snaps unexported addresses to the nearest nameduS::export. The real fault is a danglingconst View*inWebSocketListenResponse(database/src/desktop/core/web_socket_listen_provider.cc). Detach a listener while a listen response is in flight and the callback reads aViewtheSyncTreealready 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.