GetOrLoadTexture leaks a GPU texture when the same uncached path is requested concurrently

[matt-edmondson]

What happens

GetOrLoadTexture (ImGui.App/ImGuiApp.cs, lines 1630-1658) does an unsynchronized check-then-act on Textures (a ConcurrentDictionary): it checks Textures.TryGetValue(path, ...), and on a miss decodes the image and uploads a new GPU texture via UploadTextureRGBA (which marshals to the GL thread via Invoker.Invoke), then writes Textures[path] = textureInfo. There is no lock around the whole load-and-publish sequence.

Failure scenario

Two threads call GetOrLoadTexture(path) for the same not-yet-cached path at nearly the same time — plausible, since the Invoker/GL-thread marshaling machinery exists specifically to support calling into ImGuiApp from non-UI threads (e.g. background asset loading). Both threads miss the cache, both decode the image and upload a separate GPU texture, and both assign Textures[path]. Whichever assignment happens last wins; the other upload's GPU handle is never stored anywhere, so it isn't reachable by DeleteTexture(path), CleanupAllTextures(), or ReloadAllTextures() — it leaks for the life of the GL context.

Suggested fix

Guard the check-and-upload-and-publish sequence per path, e.g. ConcurrentDictionary<AbsoluteFilePath, Lazy<ImGuiAppTextureInfo>>, or a per-path lock/SemaphoreSlim, so only one load/upload happens per path even under concurrent first access.

Acceptance criteria

• Concurrent calls to GetOrLoadTexture for the same uncached path result in exactly one GPU upload for that path.
• A test covers concurrent first-access calls to GetOrLoadTexture with the same path.

[matt-edmondson]

Triage

Category: Bug
Priority: Medium
Suggested assignment: none — no specific team/area indicated; owner is the ImGuiApp texture/resource area (ImGui.App/ImGuiApp.cs)
Possible duplicate: none found — #404 is also an ImGuiApp resource-lifecycle bug filed the same day, but a distinct defect (static teardown vs. texture cache synchronization)
Already in progress: no — no open PR in the org touches this

Why Medium: a leaked GPU texture is unreachable by DeleteTexture, CleanupAllTextures and ReloadAllTextures, so it persists for the life of the GL context — but it requires a concurrent first-access race on the same uncached path, and each occurrence leaks one texture rather than growing unbounded on its own. The scenario is realistic rather than theoretical: the Invoker/GL-thread marshaling exists specifically so non-UI threads can call in, which is exactly where background asset loading would hit this.

Suggested next step: ConcurrentDictionary<AbsoluteFilePath, Lazy<ImGuiAppTextureInfo>> is the cleaner of the two options in the issue — it collapses the check-then-act into one atomic publish without introducing a per-path lock to manage. Note that Lazy with the default thread-safety mode still needs care around the Invoker.Invoke marshal to the GL thread, so the test asserting exactly one upload per path is worth writing first.

---

Generated by Claude Code