[PATCH 0/1] MR3553: opengl32: Skip debug callback messages called from native thread.

[Paul Gofman (＠gofman)]

Mesa sometimes calls debug message callback from its own Unix native thread. Then it inevitably crashes in KeUserModeCallback().

So far I spotted only harmless notification messages called this way:
```
Shader Stats: SGPRS: 24 VGPRS: 12 Code Size: 124 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
```

So I guess the best is just to ignore the callbacks called from native threads. The only other solution I see in the current architecture is to spin a PE thread from opengl and poll for debug messages, but that looks less than ideal and probably doesn't worth it.

[PATCH 1/1] opengl32: Skip debug callback messages called from native thread.

[Paul Gofman]

From: Paul Gofman

---
 dlls/opengl32/unix_wgl.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/dlls/opengl32/unix_wgl.c b/dlls/opengl32/unix_wgl.c
index a03f8337fbf..c96454c7dbf 100644
--- a/dlls/opengl32/unix_wgl.c
+++ b/dlls/opengl32/unix_wgl.c
@@ -886,8 +886,15 @@ static void gl_debug_message_callback( GLenum source, GLenum type, GLuint id, GL
     };
     void *ret_ptr;
     ULONG ret_len;
-
     struct wgl_handle *ptr = (struct wgl_handle *)userParam;
+
+    if (!NtCurrentTeb())
+    {
+        fprintf( stderr, "msg:gl_debug_message_callback called from native thread, serverity %#x, message "%.*s".\n",
+                 severity, length, message );
+        return;
+    }
+
     if (!(params.user_callback = ptr->u.context->debug_callback)) return;
     params.user_data = ptr->u.context->debug_user;

[Henri Verbeet (＠hverbeet)]

I take it most debug messages about e.g. invalid GL usage would still come from a Wine thread, right? In any case, I suppose the fprintf() ensures the actual messages stay visible, so in that sense this seems fine. This does seem like an unfortunate issue though.

[Paul Gofman (＠gofman)]

Yes, invalid GL usage still comes from Wine thread.

I don't think the problem is overall new, relatively recent change is opengl32 wow32 conversion which now crashes in KeUserModeCallback. Before that it could not work very well too, although had a chance to go unnoticed as KeUserModeCallback wasn't on the way and TEB wasn't NULL, it was from the Wine thread creating native thread.

Spinning a thread to handle these messages should be possible, but I honestly doubt that it worth the complication and an extra thread as soon as those messages are notification only.