AttachToActiveGLContext Crashed in Windows
Closed this issue · 28 comments
I have created an OpenGL context in the main window through other methods. When I use AttachToActiveGLContext to bind the current default context, my demo crashes directly, outputting: User-defined allocator is not provided. Using default allocator. Then there is no other output and it crashes directly.
I guess the created OpenGL context is being used by another thread, and then the crash occurs when the context is bound using AttachToActiveGLContext?
- OS and version you are running：Windows 10 19045.3930
- Build tools and configuration you used to build the engine： (e.g. Visual Studio 2019 Debug x64 + CMake 3.29.5)
- GPU and driver version you have installed on your system ：NVIDIA 1060 6G，4.6.0 NVIDIA 552.44
- Debug output, especially messages from Diligent：User-defined allocator is not provided. Using default allocator.
The context must be active in the thread when you call AttachToActiveGLContext.
If you use the context in multiple threads, the context must always be active in the thread whenever you call any Diligent function.
Thanks for you reply.
Is there any way to avoid the crash? How can I make AttachToActiveGLContext not crash immediately when the context is not active?
Where exactly does the crash happen?
What is the call stack?
“User-defined allocator is not provided. Using default allocator.” is the last output and then the program is crash.
The crash code maybe in:
What is the call stack?
Did you build Debug configuration?
this is my call stack.
this is my code to use AttachToActiveGLContext when have no window handle.
Did you initialize OpenGL context before calling AttachToActiveGLContext?
Where inside the AttachToActiveGLContext function does it crash?
yes，I am not sure whether initialize OpenGL context before calling AttachToActiveGLContext，because the previous part is not my responsibility, is it important to have no initial opengl context?
The program executes SetRawAllocator because output “User-defined allocator is not provided. Using default allocator.”，then crash，I can only judge by the logs.
If you don't have active GL context that you initialized, you should not be calling AttachToActiveGLContext.
Use CreateDeviceAndSwapChainGL
CreateDeviceAndSwapChainGL need the window handle parameter.
Calling AttachToActiveGLContext must surely crash if there is no active context?
CreateDeviceAndSwapChainGL need the window handle parameter
Yes, you need Window handle to create the OpenGL context on Windows.
Calling AttachToActiveGLContext must surely crash if there is no active context?
If there is no active context, you should not be calling this function.
Please take a look at the example I sent.
ok, thanks for your replay.
Is there any good way to determine whether there is an active context?
https://registry.khronos.org/EGL/sdk/docs/man/html/eglGetCurrentContext.xhtml
If you did not initialize a context, there is definitely no context.
thanks for your reply
Is there any way in Diligent Core or Diligent Engine to get the current context?
I don't completely understand the question.
On Windows, it uses the wglGetCurrentContext
If there is none, it returns an error
thanks
hello, I caught this crash code through the pdb file.
It seems that there is a problem when allocating memory. But I don't understand where the problem is. Can you find out where the problem is?
Is this related to AttachToActiveGLContext?
Yes, the problem occurs when calling AttachToActiveGLContext, more precisely in the following line.
m_AddrToPageId is a std::unordered_map, and I find it weird that the reserve function of std::unordered_map crashes.
Can you build a reproducer based on one of the Tutorials? Tutorial00_HelloWin32 in particular?
After extensive testing, we found the GPU that causes the crash: [AMD Radeon HD 8670M].
What was the issue with this GPU?
The crash on the allocator is still quite strange
When using AttachToActiveGLContext on this GPU, it crashes immediately.
I am also very troubled by this error, and in my mind, the C++ standard library is generally not a problem.
I solved this problem.
The reason is that DiligentCore uses /arch:AVX2 instruction set in MSVC compilation, but the CPU of the computer with the problem does not support avx2 instruction set, so an illegal instrcution error occurs, causing the program to crash directly.
OK, you can use the DILIGENT_MSVC_RELEASE_COMPILE_OPTIONS CMake option to disable AVX2
OK，thanks.