fix(gl-dp): load this module's GLAD table before any GL call#26
Merged
Conversation
The GL display processor crashed on the first frame (access violation, call through a null function pointer) for any standalone GL app (cube_handle_gl). Root cause: aux_ogl is a static lib, so DisplayXR-LeiaSR.dll links its OWN copy of the glad_gl* function-pointer table. The runtime (comp_gl_compositor) loads its own copy, but that does not populate the plug-in's — so the plug-in's glad_glViewport (the first GL call in process_atlas) was null and dereferencing it faulted. Fix: load the plug-in module's GLAD table once in leia_dp_factory_gl, mirroring the runtime's loader (wglGetProcAddress with an opengl32.dll fallback). The compositor has made the GL context current before invoking the factory, so the load succeeds there. D3D11/D3D12/VK DPs were unaffected (no GLAD dependency). Diagnosed via procdump + cdb: rip=0, faulting frame in DisplayXR-LeiaSR.dll calling [DisplayXR-LeiaSR+0x277f0], with the whole surrounding pointer region all-zero (an unloaded dispatch table); reproduced identically on a runtime baseline, confirming it is a plug-in bug. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The GL display processor crashed on the first frame (access violation — call through a null function pointer) for any standalone GL app (
cube_handle_gl). D3D11/D3D12/VK were unaffected.Root cause
aux_oglis a static lib, soDisplayXR-LeiaSR.dlllinks its own copy of theglad_gl*function-pointer table. The runtime (comp_gl_compositor) loads its own copy at compositor-create, but that does not populate the plug-in's table. The first GL call inprocess_atlas—glViewport(0, 0, target_w, target_h)— therefore dereferenced a nullglad_glViewportand faulted.Diagnosed via procdump + cdb:
rip=0, faulting frame insideDisplayXR-LeiaSR.dllcalling[DisplayXR-LeiaSR+0x277f0], with the whole surrounding pointer region all-zero (an unloaded dispatch table). Reproduced identically against a stock runtime baseline, confirming a plug-in bug (not the runtime).Fix
Load this module's GLAD table once in
leia_dp_factory_gl, mirroring the runtime's loader (gladLoadGLUserPtrwithwglGetProcAddress+ anopengl32.dllfallback). The compositor has made the GL context current before invoking the factory, so the load succeeds there.Verification
Built the plug-in, deployed to
C:\Program Files\DisplayXR\Plugins\LeiaSR\, rancube_handle_glon the Leia panel: now renders sustained frames (previously crashed after frame 1). Visually confirmed correct on the live display.🤖 Generated with Claude Code