Graphic Layer related crashes
-
Hi,
We have QT Application where we have one of widgets contents is drawn using openGL code in Mac. Mac OS initiated windows animations ends up clashing with our internal GL code context and leads to crashing. Since GL context code used in internal application does not expect any other operations except application initiated ones.Is there a way to turn of Mac OS initiated windows animations to stop these unintended behaviors in QT application ?
-
Hi and welcome to devnet,
What version of macOS are running ?
What version of Qt are you using ?
Can you provide a minimal compilable example that shows that behaviour ? -
This is not consistently reproducible and that is the major problem for us to identify better fix.
But we nailed down the use cases to where the QT window gets closed and reopened and we see MAC animations conflicting during those actions.
Crash Stack trace is as below:
Thread 16 Crashed:: Dispatch queue: CA DispatchGroup
0 libsystem_kernel.dylib 0x00007fff7c8ea23e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff7c9a0c1c pthread_kill + 285
2 libsystem_c.dylib 0x00007fff7c8531c9 abort + 127
3 libGPUSupportMercury.dylib 0x00007fff6b07b1c5 gpusGenerateCrashLog + 168
4 com.apple.AMDRadeonX4000GLDriver 0x000000011e8a5c23 gpusKillClientExt + 9
5 libGPUSupportMercury.dylib 0x00007fff6b07c590 gpusSubmitDataBuffers + 165
6 com.apple.AMDRadeonX4000GLDriver 0x000000011e87e622 glrATI_Hwl_SubmitPacketsWithToken + 110
7 com.apple.QuartzCore 0x00007fff5a5c2e09 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 2001
8 com.apple.QuartzCore 0x00007fff5a5c23ca -[CAOpenGLLayer _display] + 579
9 com.apple.AppKit 0x00007fff4ce69b97 -[NSOpenGLLayer display] + 240
10 com.apple.QuartzCore 0x00007fff5a53c2f0 display_callback(void*, void*) + 64
11 com.apple.QuartzCore 0x00007fff5a53c24d CA::DispatchGroup::dispatch(bool) + 49
12 libdispatch.dylib 0x00007fff7c75cdcf _dispatch_client_callout + 8
13 libdispatch.dylib 0x00007fff7c763124 _dispatch_lane_serial_drain + 618
14 libdispatch.dylib 0x00007fff7c763bdc _dispatch_lane_invoke + 388
15 libdispatch.dylib 0x00007fff7c76c090 _dispatch_workloop_worker_thread + 603
16 libsystem_pthread.dylib 0x00007fff7c99d60b _pthread_wqthread + 409
17 libsystem_pthread.dylib 0x00007fff7c99d405 start_wqthread + 13we are currently using NSOpenGLView backed by NSOpenGLLayer, and preform the setup as called out in option2 in the below answer for our GL based rendering in QT widget :
https://stackoverflow.com/questions/7610117/layer-backed-openglview-redraws-only-if-window-is-resized?answertab=votes#tab-top -
I have always believed these macOS graphics driver crashes are caused by the Apple graphics driver not handling heavy use of graphics memory. I develop a molecular visualization Qt app called ChiimeraX. Here are 41 macOS crash reports from the past 2 years that include the Apple graphics driver call
gpusKillClientExthttps://plato.cgl.ucsf.edu/trac/ChimeraX/search?q=gpusKillClientExt
When can the Apple graphics driver make that call to kill the client? The only way I believe OpenGL should crash is if you pass it an invalid pointer. I am pretty confident that is not happening in the above 41 cases. And I have tried passing a bad pointer and it in fact does not cause this kind of crash.
Some of the crashes are in Qt rendering the GUI and some are in our molecular graphics rendering (using PyOpenGL).
I am quite interested in the theory that Mac window system animations are associated with these crashes. I have no evidence that they are involved in the above 41 crash reports.
The above crash reports use Qt 5.12.3, Qt 5.12.9, Qt 5.15.1. Currently we use 5.15.2 and I have little doubt we will continue to see them. I think this is purely and Apple graphics driver problem. Apple's OpenGL graphics drivers have been poor quality for decades, and since they switched macOS to their proprietary Metal graphics API they have little incentive to care about whether OpenGL works reliably.
I think great progress could be made if someone with access to the Apple driver source code could explain when gpuKillClientExt is called, for example from gpusSubmitDataBuffers, a common crash sequence. My best guess is 1) driver memory allocation fails, 2) driver crashes.
