DCL.Diagnostics.EcsSystemException: [ResetGltfContainerSystem]

[sentry]

Sentry Issue: UNITY-EXPLORER-P83

System.NullReferenceException: Object reference not set to an instance of an object.
  File "il2cpp-codegen.h", line 633, in DereferenceFinalOperation
  File "ECS.Unity__2.cpp", line 29779, in DereferenceFinalOperation
  File "ECS.Unity__2.cpp", line 29743, in DereferenceFinalOperation
  File "ECS.Unity__2.cpp", line 29728, in Dereference
  File "il2cpp-codegen.h", line 633, in TryReleaseAsset
...
(23 additional frame(s) were not displayed)

DCL.Diagnostics.EcsSystemException: [ResetGltfContainerSystem]
  File "ECS.Core.cpp", line 7481, in Update
  File "il2cpp-codegen.h", line 633, in Update
  File "Generics__20.cpp", line 18515, in Update
  File "Generics__17.cpp", line 24149, in UpdateInternal
  File "Generics__17.cpp", line 11631, in UpdateInternal
...
(9 additional frame(s) were not displayed)

This issue was automatically created by Sentry via Explorer Alpha Github Issue Creation

[github-actions]

Automated Triage

Issue type	bug
Affected area	ResetGltfContainerSystem (ECS asset cleanup)
Feature category	Primary (Stability & Crashes)
Severity	SEV-2 → 1-high

Reasoning: This is a crash in the Primary category (Stability & Crashes) affecting users who trigger GLTF asset loading/unloading flows. The NullReferenceException during TryReleaseAsset suggests a dangling reference during asset cleanup. While confirmed in production via Sentry, it affects a subset of users rather than blocking all users, placing this at SEV-2 with a hotfix required per the Primary category classification.

Labels applied: bug, 1-high

---

Auto-triaged. If labels are incorrect, update issue triage categories or severity policy and re-run triage.

[decentraland-bot]

Root cause analysis

Traced through decentraland/unity-explorer source (main branch). The Sentry stack shows a NullReferenceException inside DereferenceFinalOperation, called via Dereference ← TryReleaseAsset ← ResetGltfContainerSystem:

• ResetGltfContainerSystem.cs:64-71 (TryReleaseAsset) calls cache.Dereference(component.CacheKey, result.Asset) when a scene removes/dirties a GltfContainer component (e.g. the Genesis Plaza fishing pond spawning/despawning its GLTF props).
• GltfContainerAssetsCache.cs:117-126 (DereferenceFinalOperation) does asset.Root.transform.SetParent(...) / asset.Root.SetActive(false) — this throws NRE if asset.Root is already null/destroyed.
• That exception gets wrapped into an EcsSystemException by BaseUnityLoopSystem.cs:66-70, matching the [Error] [ResetGltfContainerSystem] message reported in Slack.

Why this causes a full scene freeze, not just a logged error

SceneExceptionsHandler.cs:18 sets ENGINE_EXCEPTIONS_PER_MINUTE_TOLERANCE = 3 — once this exception fires 3+ times within 60 seconds, the handler sets SceneState.EcsError (SceneExceptionsHandler.cs:153). Every synced system group (Init/Simulation/Presentation/PreRendering — SyncedGroup.cs:59-84) checks sceneStateProvider.State != Running/Starting and stops updating once it isn't. So the entire scene halts, not just the GLTF systems — this is the "Genesis Plaza scene code freezes" behavior reported.

Likely trigger

The fishing pond likely spawns/despawns many GLTF-container entities in quick bursts (bites/catches), so a burst of HandleComponentRemoval/InvalidatePromise calls hits the same asset's Root after it's already been released/destroyed — e.g. evicted by GltfContainerAssetsCache.Unload(), or a structural-change-during-iteration hazard (RemoveAnimationMarker does World.TryRemove<LegacyGltfAnimation> mid-query, which the code's own comment flags as invalidating ref/in args). Either way this looks like a double-release / stale-reference bug in the GLTF asset cache, not something scene creators can work around at the content level.

Suggested fix

Guard DereferenceFinalOperation against a null/destroyed asset.Root (log-and-skip instead of throwing), and audit whether ResetGltfContainerSystem can double-dereference the same GltfContainerAsset or is affected by structural changes mid-query.

Workaround until fixed

Teleporting out and back into the scene (or reconnecting) rebuilds the scene facade and clears SceneState.EcsError — there's no in-scene recovery once the tolerance is exceeded.

---

Posted by Jarvis (Decentraland Slack agent) at the request of Alejandro Picazo, following up on Slack thread discussion.

[decentraland-bot]

Follow-up: why this doesn't reproduce as easily on the identical scene deployed as a World

The exact same scene (display.title: "Genesis Plaza", same main.crdt/bin/index.js, same asset bundle) is also deployed as the World dclexperience.dcl.eth. The bug is not currently reproducing there under casual solo testing, despite being the identical scene code. This looks like a load/concurrency-dependent race condition rather than a Genesis-City-vs-World code difference:

Population gap (live data via Places API):

• Genesis Plaza (Genesis City): user_count: 20 at time of check — and higher at peak, as the official spawn point.
• dclexperience.dcl.eth World: total: 0 — essentially no concurrent traffic.

Why population affects trigger frequency:

1. Event-rate threshold — SceneExceptionsHandler.cs:18 requires the underlying NullReferenceException (in DereferenceFinalOperation) to fire 3+ times within 60 seconds before SceneState.EcsError is set and the scene freezes (SceneExceptionsHandler.cs:153). The fishing pond's GltfContainer add/remove/dirty churn is driven by scene logic shared across everyone connected to that scene instance, not just the local player's actions. With ~20 concurrent players potentially interacting with (or triggering LOD/visibility churn near) the pond, GLTF churn events happen far more frequently per unit time than with a single solo tester — turning a per-event-rare race into something that reliably crosses the 3-in-60s threshold.
2. Cache eviction pressure — GltfContainerAssetsCache.Unload() is a budget-based LRU eviction (Unload(IPerformanceBudget frameTimeBudget, int maxUnloadAmount)) that only actually disposes/destroys a GltfContainerAsset.Root under real memory/frame-budget pressure. A busy Genesis Plaza (20 avatars, wearables, other loaded content) creates that pressure, making eviction — and the resulting dangling asset.Root == null — far more likely to actually happen. A near-empty World instance has little else loaded, so the cache rarely needs to evict, meaning the "asset already disposed while still referenced" precondition may simply never arise during a short solo test.

Practical implication for reproduction/testing: to reproduce this reliably on dclexperience.dcl.eth (or any low-traffic deployment), it likely needs multiple concurrent testers actively using the pond at once (or artificial memory/load pressure), rather than one person fishing alone. This is useful context for the fix's test coverage — a fix validated only in a quiet single-user session may look "resolved" without actually addressing the underlying race.

---

Posted by Jarvis (Decentraland Slack agent) at the request of Alejandro Picazo, following up on Slack thread discussion.