baldurk
Null access violation when sharing non-core and core OpenGL context created in a separate thread.
Description of Bug
Whenever a non-attributed OpenGL context is created prior to an attributed OpenGL context in another thread, and the first context ( non-attributed) create shareable OpenGL container objects such as an FBO, RenderDoc will crash whenever the object is accessed after the attributed context is created and made current to its thread. The issue was discovered when developing an Uno SDK application that utilizes Skia for the UI rendering. Uno Skia will create a compatibility profile context, while my application code creates a core OpenGL context which is shared with the Uno-Skia created context.
Steps to reproduce
There is no capture to produce as this issue happens during the startup of the application.
Environment
- RenderDoc version: 1.38
- Operating System: Windows 10
- Graphics API: OpenGL
I downloaded the source and build the 'Development' configuration, and debugging the issue indicates that the call to create the GLResource resource via 'FramebufferRes' @ line 1581 in gl_framebuffer_funcs.cpp( WrappedOpenGL::glBindFramebuffer) will return a 'GLResource' that is 'owned' or 'belongs' to the shared group if FBO are shareable on the given implementation. In my case I'm using an AMD 470 RX which RenderDoc indicated FBO are shareable. If the <m_CurrentResources> in GLResourceManager is inspected at this point, you will notice that the FBO is already in the container and owned by the non-attrib context. Whenever a lookup in <GLResourceManager> happens with the return 'GLResource', what occurs is that a new entry is added to the map, but its states( record) is not set, any access thereafter will result in a null access violation.
The crux of the issue I believe stems from the fact that non-attributed context does not a vendor check ( invoke DoVendorChecks ) and the first attributed context will. So this issue seems likely to occur if an attributed context ever gets created after a non-attributed one that already contained resources.
Currently I worked around the issue ( may only be valid for my platform) by just assuming ALL FBOs except FBO 0 is shareable in FramebufferRes
For steps to reproduce, as detailed in the documentation about filing issues please share a specific and complete reproducible test case that I can use to investigate the problem, such as a capture or executable depending on what is most relevant to the bug. Without a repro case it is usually impossible for me to replicate the situation you are running into, and it can easily waste time trying to reproduce a problem that is not as expected or described.
Please ensure that you have run your program on its own (not from RenderDoc) with API validation and have checked that your program does not produce any validation errors or warnings, since RenderDoc does not handle invalid API use. Make sure that you have updated your graphics drivers and if you have a different GPU or hardware available try testing on that to eliminate your hardware as a potential problem.
If you can't share your test case publicly due to privacy or NDA concerns you can contact me via email. Even if you can't share your test case privately email is typically the best avenue if you can discuss more details than you can privately.
Closing this due to lack of activity from the reporter and no further information to investigate.
If you are the reporter and this bug is still a problem for you, or you are someone finding this issue and you believe this bug is still a problem and you have more information to share, please do not comment here and instead please open a new issue. You can reference this issue if you wish, but opening a new issue prevents confusion of accidentally linking two unrelated bugs and means that each issue can be handled in a clean process.