ImGui: guard ShowCursor against a torn-down context - #267
Conversation
ShowCursor was the only entry point not checking isContextInitialized; a disconnect path calling it after Shutdown() crashed on a null context. Shutdown() also cleared the flag after DestroyContext(); clear it first.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe ImGui wrapper now marks the context as uninitialized before shutdown operations and avoids ChangesImGui context safety
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This localized change prevents cursor updates after ImGui teardown and closes the shutdown ordering window; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
User's workaround was to force GPU for both |
Summary
ImGUI::Wrapper::ShowCursor()was the only public entry point on the wrapperthat did not check
isContextInitializedbefore touching ImGui state. A clientteardown path (disconnect handling → release control locks →
ShowCursor(false))ran after
Wrapper::Shutdown()and dereferenced a destroyed ImGui context.Found while symbolizing a user-submitted crash dump from a Release build of a
UE 4.27.2 title on the D3D12 backend.
Crash signature
ImGui::GetIO()resolves toGImGui->IO. With a null context that isnullptr + offsetof(ImGuiContext, IO)=0x28(matchesrax), andImGuiIO::MouseDrawCursorat+0x50puts the store at0x78(matches thefaulting address).
rbx=0is thefalsebeing written.Release-only in practice:
ImGui::GetIO()normally carriesIM_ASSERT(GImGui != NULL), which/DNDEBUGremoves, degrading the guard intoa raw null dereference.
Two defects fixed
ShowCursornever checked the flag. Every other gated entry point(
Init,Shutdown,Render,OnDeviceLost,OnDeviceReset) does.Shutdown()clearedisContextInitializedafterDestroyContext().That left a window in which the flag claimed the context was live while the
backends were already shut down and the context destroyed — so the guard in
(1) alone would not cover a caller landing inside it. The flag is now cleared
up front, immediately after the early-out.
Investigation notes: GPU was ruled out, not a factor
Recording this so it is not re-chased. The reporting machine is a hybrid-graphics
laptop, and the crash context showed the title rendering on the integrated
GPU (
Misc.PrimaryGPUBrand= Intel iGPU; only the Intel D3D12 UMD was loaded inthe process, the NVIDIA D3D UMD never was) despite a discrete GPU being present.
That initially looked causal — a renderer hook failing to attach would leave
isContextInitialized == falseand reach the same defect. It was ruled out:control panel) did not stop the crash.
Inithad succeeded and the context genuinely existed.Conclusion: this is a teardown-ordering bug, not a renderer-init bug. The GPU
selection oddity is real but separate, and is being tracked downstream.
Secondary observation (not addressed here)
CMAKE_CXX_FLAGS_RELEASEis/O2 /Ob2 /DNDEBUGwith no/DEBUGat link, soRelease builds ship without a PDB and user crash dumps cannot be symbolized
without reproducing the exact toolchain. Adding
/Ziplus/DEBUG:FULL /OPT:REF /OPT:ICF /PDBALTPATH:%_PDB%was measured on a real buildof this framework to cost exactly one 4 KB page of
SizeOfImagewhile leaving.textbyte-identical./OPT:REF /OPT:ICFmust be explicit —/DEBUGsilentlydefaults them off, which would change code layout. Happy to open a separate PR
if that is wanted.
Testing
Not reproduced locally — the crash requires the teardown ordering seen on the
reporting machine. The fix was verified by inspection against the symbolized
stack, and the register arithmetic above accounts for the faulting address
exactly. No behavioural change when the context is live; when it is not,
ShowCursorbecomes a no-op, which is correct (no cursor to draw).Summary by CodeRabbit