[PATCH v3 3/6] user32: Implemented RegisterDeviceNotification

[Zebediah Figura]

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?