-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle overwrite #1203
Comments
This is a race condition between BeginPaint and WM_ERASEBKGND, https://github.com/otya128/winevdm/blob/master/user/message.c#L2438. Since BeginPaint doesn't release the thunk lock but WINPROC_CallProc32ATo16 doesn't wait on it probably need a separate critical section around the handle allocation. |
Try #1204 |
Thanks. That looks like it has fixed the issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A 3rd-party application that calls Windows UI GDI functions on two threads at same time can cause handle overwrite
Expected behavior
Handles should not get overwritten and lost which leads to UI corruption/missing window objects and potentially crashes
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
Additional context
I have included a WINEDEBUG log. I tweaked the logging in wow_handle.c to use TRACE rather than DPRINTF so the thread ids are recorded to help show the issue.
I have highlighted an some examples of the issue like this:
WINEDEBUG.zip
The text was updated successfully, but these errors were encountered: