Improper message recursion revealed by recent desktop window changes

[Jesse Allen]

On 3/29/06, Troy Rollo <wine at troy.rollo.name> wrote:
> The recent changes to the desktop have revealed a problem with recursive
> processing of X messages. The problem started to manifest with commit
> 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack
> that looks like this:
>
>         <application Window procedure>
>         WINPROC_wrapper
>           ...
>         CallWindowProcW
>          ...
>         SendMessageW
>         X11DRV_SetWindowPos
>         SetWindowPos
>         X11DRV_ConfigureNotify
>         process_events
>         X11DRV_MsgWaitForMultipleObjectsEx
>         wait_message_reply
>         send_inter_thread_message
>         SendMessageTimeoutW
>         SendMessageW
>         send_parent_notify
>         DestroyWindow
>
> In other words, a destroy notification is being sent to the parent window with
> SendMessageW, and before that message returns an unrelated X message is
> processed. Under Windows the equivalent could never happen - if a thread is
> in SendMessage(), the only messages that can be delivered to it are ones sent
> by SendMessage() from another thread.
>
> The consequences of this can be unpleasant if the code that processes (in this
> case a window movement notification) the message interferes with state that
> is being dealt with in earlier stack frames.


Yep, that's why the launching of War3 seems to only paint explorer or
the launch window depending on how I hacked wine.

This is the problem exhibited in bugs 4948, 4897, and 4847.


>
> wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with:
>
> res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue,
>                                              INFINITE, QS_ALLINPUT, 0 );
>
> The brute-force approach of changing this to the following makes the
> application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT
> and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to
> change I thought it best left to people with more familiarity with it.
>
> --
> Troy Rollo - wine at troy.rollo.name
>
>
>


Last thing I did today was looking at the message passing and signal
handling.  The signal handling doesn't look any different than before.
 I figured something could be up with the message handling as it
seemed one thread was stomping on another but I don't know anything
about wineserver.  I'll take a better look tomorrow!

Jesse