Bug 1453 - glCreateShader crashes on MacOS, works on windows
Summary: glCreateShader crashes on MacOS, works on windows
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 2.6.0
Hardware: All all
: P4 normal
Assignee: Sven Gothel
Depends on:
Reported: 2023-09-22 20:26 CEST by Harvey Harrison
Modified: 2023-09-27 18:58 CEST (History)
1 user (show)

See Also:
SCM Refs:
Workaround: ---

Self contained test case (3.96 KB, text/plain)
2023-09-22 20:26 CEST, Harvey Harrison
vertex shader code (1.04 KB, text/plain)
2023-09-22 20:27 CEST, Harvey Harrison
non core context shader (1.06 KB, text/plain)
2023-09-22 20:27 CEST, Harvey Harrison

Note You need to log in before you can comment on or make changes to this bug.
Description Harvey Harrison 2023-09-22 20:26:29 CEST
Created attachment 861 [details]
Self contained test case

Self-contained test case has been distilled from the JaamSim project:

- creates separate render thread
- inits gl caps and a dummy drawable to set up a context
- first call to glCreateShader blows up on MacOS, is fine on windows.

I've left the read of the actual vertex shader code, but it currently crashes before actually doing anything with the shader source. So it doesn't actually matter what the contents of the shader are.
Comment 1 Harvey Harrison 2023-09-22 20:27:13 CEST
Created attachment 862 [details]
vertex shader code
Comment 2 Harvey Harrison 2023-09-22 20:27:38 CEST
Created attachment 863 [details]
non core context shader
Comment 3 Harvey Harrison 2023-09-22 20:39:46 CEST
I haven't yet validated the test case against the failures we observed in jaamsim, but from the jaamsim side this test case was distilled from:

v2.4.0-rc-20200202  - works just fine

v2.4.0-rc-20210111 - glCreateShader crashes with error 1286 which is FrameBuffer not ready

v2.5.0 fails on intel macs and M1/M2 based macs with same error code
Comment 4 Harvey Harrison 2023-09-27 17:26:20 CEST
Some resolution to this:

We were using the following to get a dummy drawable previously, this works fine on windows, but on MacOS for some reason the context returned from getContext had no framebuffer bound by default, causing the call to glCreateShader to error, glCheckFramebufferStatus returns gl_framebuffer_undefined.

dummyDrawable = GLDrawableFactory.getFactory(glp).createDummyAutoDrawable(null, true, caps, null);

We've moved to just creating an offscreen drawable which returns a context that does have a framebuffer bound.

dummyDrawable = GLDrawableFactory.getFactory(glp).createOffscreenAutoDrawable(null, caps, null, 16, 16);
Comment 5 Sven Gothel 2023-09-27 18:57:20 CEST
(In reply to Harvey Harrison from comment #4)
Indeed that is exactly as both API entries shall behave,
i.e. 'dummy' implies not necessarily creating a usable surface (FBO or otherwise)
and 'offscreen' implies a usable surface (usually FBO).

And I found my commit where I have tightened the 'dummy' implementation
to favor a surfaceless context to query information.


Commit ead8651394c792950025114cfcb6476e8b82bf50
Date:   Sat Mar 4 19:57:39 2023 +0100

    GLDrawableFactoryImpl:createDummyDrawable(): Similar to createOffscreenDrawable() prefer createSurfacelessImpl() over createDummySurfaceImpl() to reduce resources (no actual window)
    This enhances the 'dummy drawable' use-case implementation, i.e. for shared context.