On Thu Oct 16 07:06:10 2025 +0000, Rémi Bernon wrote:
> Sorry, there's no general method to debug this and there's many possible
> root causes. This indicates that one thread is waiting on a critical
> section forever as another thread didn't release it (possibly crashed
> while holding it, but could be something else). The missing name
> indicates that it's probably a critical section created by the application.
> You can open a bug report on the website above, with details about the
> application you are trying to run if you can, and log file of Wine
> output with `WINEDEBUG=+wgl` environment variable set for instance, this
> might give some clue, or someone (including myself) can then try to
> reproduce the issue and debug it.
thinks,I have another question.
Window DC calls the function set_dc_opengl_drawable( dce-\>hdc, NULL ) to release opengl-drawable through release_dce or release_dc.
After this submission:[**win32u: Don't store the window OpenGL drawables on the DCs.**](https://gitlab.winehq.org/wine/wine/-/merge_requests/8958/diffs?com… where is the resource release for opengl-drawable? I don't seem to have seen it in this submission. The release of opengl_drawable should be done by the window.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118688
On Thu Oct 16 07:05:06 2025 +0000, li xiao wrote:
> thinks , How to debug issues related to win32u: opengl_drawable when
> encountering a deadlock。
> for example:
> <table>
> <tr>
> <td>
> `01a0:err:sync:RtlpWaitForCriticalSection section
> 00007F4A4ACC5570 "?"` `wait timed out in thread 01a0, blocked by 0134,
> retrying (60` `sec).`
> </td>
> </tr>
> </table>
> This issue is caused by opengl_drawable lifetime.
Sorry, there's no general method to debug this and there's many possible root causes. This indicates that one thread is waiting on a critical section forever as another thread didn't release it (possibly crashed while holding it, but could be something else). The missing name indicates that it's probably a critical section created by the application.
You can open a bug report on the website above, with details about the application you are trying to run if you can, and log file of Wine output with `WINEDEBUG=+wgl` environment variable set for instance, this might give some clue, or someone (including myself) can then try to reproduce the issue and debug it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118684
On Mon Oct 13 10:09:28 2025 +0000, Rémi Bernon wrote:
> Hi, sorry if this has caused some more issues but if there's a bug
> please submit a bug report to https://bugs.winehq.org with some more
> details about it happens and how to reproduce it.
> Regarding the `opengl_drawable` member in the DC structure, it's still
> being used for non-Window DCs, like memory DCs, which need to keep a
> reference on their eventual OpenGL surface.
thinks , How to debug issues related to win32u: opengl_drawable when encountering a deadlock。
This issue is caused by opengl_drawable lifetime.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118683
The fix ensures the window manager knows the correct stacking order
by setting the transient hint to the **insert_after** window when when using
**SetWindowPos** with **insert_after** parameter.
Signed-off-by: Zhao Yi <zhaoyi(a)uniontech.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9181
When scaling applies, after a call to SetCursorPos(), a subsequent call to GetCursorPos() may not return the exact coordinates set, which an app may interpret as mouse movement.
--
v2: win32u, server: Use float values to track mouse cursor location.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9171