Improper message recursion revealed by recent desktop window changes
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. 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(a)troy.rollo.name
Troy Rollo <wine(a)troy.rollo.name> writes:
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.
I committed a few fixes that should help, please give it a try. -- Alexandre Julliard julliard(a)winehq.org
On Friday 31 March 2006 02:41, Alexandre Julliard wrote:
I committed a few fixes that should help, please give it a try.
The problem is fixed (so the app now works) although I am still getting the pack_message FIXMEs - it is possible though that this is a different problem that was masked by the earlier one. I will investigate further. -- Troy Rollo - wine(a)troy.rollo.name
Troy Rollo <wine(a)troy.rollo.name> writes:
The problem is fixed (so the app now works) although I am still getting the pack_message FIXMEs - it is possible though that this is a different problem that was masked by the earlier one. I will investigate further.
Yes, the pack_message thing is a different problem. It shouldn't cause any harm, except maybe causing the desktop window to not be repainted properly in desktop mode. -- Alexandre Julliard julliard(a)winehq.org
On 3/30/06, Alexandre Julliard <julliard(a)winehq.org> wrote:
Troy Rollo <wine(a)troy.rollo.name> writes:
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.
I committed a few fixes that should help, please give it a try.
Ok, those patches didn't seem to help. I tried to compare more closely my stack in my program with his. Instead of DestroyWindow, my app is calling ShowWindow, so during a SendMessageW I believe of WM_NCACTIVATE, it gets stuck. The instruction is int 80 so I believe that means it is going to do a system call? If 0x8 thread gets killed or you step until it ends, the other thread will start working again. If you try cont, it remains stuck. Well you can see the my winedbg session at this link. ftp://resnet.dnip.net/ShowWindowProblem.txt Jesse
participants (3)
-
Alexandre Julliard -
Jesse Allen -
Troy Rollo