On 5/19/19 11:59 AM, Marvin wrote:
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=52472
Your paranoid android.
=== debian9 (32 bit WoW report) ===
user32: msg.c:8713: Test failed: WaitForSingleObject failed 102 msg.c:8719: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x000f instead msg.c:8719: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0014 instead msg.c:8719: Test failed: destroy child on thread exit: 2: the msg sequence is not complete: expected 0014 - actual 0000
I took the time to look into this. As it happens it's very tricky. It's a regression brought on by 08b19c6f673837b960c460b17601979aa595470f. Since we're no longer waiting for the grandchild window to destroy itself, the thread exits immediately after notifying the grandchild with WM_WINE_DESTROYWINDOW, causing the server to clean up both the child and grandchild out from under user32's nose. The grandchild never receives WM_WINE_DESTROYWINDOW because the server has emptied the message queue as part of cleaning up the window. But user32 doesn't realize the window was destroyed, so IsWindow() continues to return TRUE.
This could be solved by restoring synchronous SendMessage() only in the case of thread exit, but it seems rather likely that a similar race could occur as Andrew was trying to fix. On the other hand I get the impression that we do really want to make sure all child windows are cleaned up when a parent window is destroyed. At the risk of shouting into the void, is there anything we can do about this regression?