http://bugs.winehq.org/show_bug.cgi?id=4166
Summary: deadlock in GlobalUnlock Product: Wine Version: 0.9.2. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: wine-kernel AssignedTo: wine-bugs@winehq.org ReportedBy: arieldembling@gmail.com
Hello,
I'm running a program under Wine which opens a modal window, but under certain conditions it freezes after closing that window and returning focus to the previous one. The backtrace indicates this could be a Wine problem (I guess it's a deadlock or starvation of some kind, but my knowledge of Wine isn't deep enough to diagnose this). The fact that this program has been running fine for years under native Windows systems suggests Wine should be the cause too.
The program I'm running is prowin32.exe, which is the Progress client environment, running a Progress application called MFG/pro made by a company called QAD (see www.qad.com). You won't be able to find a demo of this program on the internet, but I'm willing to do any tests that you need.
This MFG/pro application consists of lots of files (modules) which are executed by Progress' prowin32.exe and which call each other as the need arises. At the moment that the problem appears, prowin32.exe has just finished executing one of those modules, and is returning the control to the caller module. Also, it is destroying one window (which was modal, and used for data input) and SHOULD give focus back to another existing window, but this does not happen. Instead, it just hangs there.
This problem is somewhat hard to reproduce, because the test case is not that common. There could be some dependency on the amount of data that's entered on the modal window (or maybe on the data itself), but maybe it's something else. Once a test case is found, it's reproducible almost every time. I say "almost" because at least with an older version of Wine the problem disappeared if the wine-preloader process was being strace'd (I thought it was some race condition), but that doesn't seem to happen anymore with version 0.9.2. So now we do have a 100% reproducible bug (the race condition might still be present, but if so the now it's easily won).
I tested this with several Wine & Linux versions, and it's present in all of them. The latest Wine version I've tested is 0.9.2 (I used the CentOS binaries provided at winehq.com), running under Linux 2.6.14.4, but was present back in Wine 20040813 and with Linux 2.6.3. I didn't test Wine 0.9.3 because the pre-compiled binaries for CentOS still don't exist, but I've seen the changelog and couldn't find anything that seemed to be related to this bug.
This is the backtrace before triggering the problem (with the modal window open and a message box waiting for input):
----------------------------- Backtrace: =>1 0xffffe40e (0xffffe40e) 2 0x7ffd9872 NTDLL_wait_for_multiple_objects in ntdll (0x7ffd9872) 3 0x7ffd9968 NtWaitForMultipleObjects in ntdll (0x7ffd9968) 4 0x7fcbc47f WaitForMultipleObjectsEx in kernel32 (0x7fcbc47f) 5 0x7e6e49f8 X11DRV_MsgWaitForMultipleObjectsEx in winex11.drv (0x7e6e49f8) 6 0x7f7959d4 GetMessageW in user32 (0x7f7959d4) 7 0x7f760f92 DIALOG_DoDialogBox in user32 (0x7f760f92) 8 0x7f762aaa DialogBoxIndirectParamAorW in user32 (0x7f762aaa) 9 0x7f762af8 DialogBoxIndirectParamW in user32 (0x7f762af8) 10 0x7f79a121 MessageBoxIndirectW in user32 (0x7f79a121) 11 0x7f79a2dd MessageBoxIndirectA in user32 (0x7f79a2dd) 12 0x7f79a3e7 MessageBoxExA in user32 (0x7f79a3e7) 13 0x7f79a42b MessageBoxA in user32 (0x7f79a42b) fixme:dbghelp_msc:pe_load_debug_directory This guy has FPO information 14 0x0050951d wwDelToolTipByRect in prowin32 (0x0050951d) 15 0x00629d0b umGetTypeName in prowin32 (0x00629d0b) 16 0x0075928d rnsysdial in prowin32 (0x0075928d) 17 0x005c1603 fmdstest in prowin32 (0x005c1603) 18 0x005ab773 scfld in prowin32 (0x005ab773) 19 0x0063cd4b umeDispatchEvent in prowin32 (0x0063cd4b) 20 0x005088de wwCalcListSize@24 in prowin32 (0x005088de) 21 0x00746b39 rnuUpdPrep in prowin32 (0x00746b39) 22 0x00427597 rllbk in prowin32 (0x00427597) 23 0x0040b4e2 drcargs in prowin32 (0x0040b4e2) 24 0x004556f6 csstr_sender_handle_problems in prowin32 (0x004556f6) 25 0x0077d18e utgetdrv in prowin32 (0x0077d18e) 26 0x7fca75db in kernel32 (+0x475db) (0x7fca75db) 27 0xb7ee39fd (0xb7ee39fd) -----------------------------
And this is the backtrace once the window has been closed and the whole program is frozen. If I understand it right, GlobalUnlock is waiting for something that won't happen, i.e. deadlock or starvation. ----------------------------- =>1 0xffffe410 (0xffffe410) 2 0xb7dca531 (0xb7dca531) 3 0x7fc87277 GlobalUnlock in kernel32 (0x7fc87277) 4 0x0050fa92 DoRangeSelect in prowin32 (0x0050fa92) 5 0x004de415 wwCreateFrame in prowin32 (0x004de415) 6 0x7f7c0177 WINPROC_wrapper in user32 (0x7f7c0177) 7 0x7f7c0545 WINPROC_wrapper in user32 (0x7f7c0545) 8 0x7f7c6b24 CallWindowProcW in user32 (0x7f7c6b24) 9 0x7f790006 in user32 (+0x60006) (0x7f790006) 10 0x7f79046c SendMessageTimeoutW in user32 (0x7f79046c) 11 0x7f7904c1 SendMessageW in user32 (0x7f7904c1) 12 0x7f7b7a74 in user32 (+0x87a74) (0x7f7b7a74) 13 0x7f7b8e57 DestroyWindow in user32 (0x7f7b8e57) 14 0x004ceb10 wwGoThroughAllWidgets in prowin32 (0x004ceb10) 15 0x004e0438 Frame_OnCommand in prowin32 (0x004e0438) 16 0x006944da umSellistGetAttr in prowin32 (0x006944da) 17 0x0069d7d5 umFrmSetFG in prowin32 (0x0069d7d5) 18 0x00631efc umWindowDoResize in prowin32 (0x00631efc) 19 0x00643de9 ioInitProc in prowin32 (0x00643de9) 20 0x00643b9d umeGetFrameField in prowin32 (0x00643b9d) 21 0x00598b12 rnproc_entry in prowin32 (0x00598b12) 22 0x005ab773 scfld in prowin32 (0x005ab773) 23 0x0063cd4b umeDispatchEvent in prowin32 (0x0063cd4b) 24 0x005088de wwCalcListSize@24 in prowin32 (0x005088de) 25 0x00746b39 rnuUpdPrep in prowin32 (0x00746b39) 26 0x00427597 rllbk in prowin32 (0x00427597) 27 0x0040b4e2 drcargs in prowin32 (0x0040b4e2) 28 0x004556f6 csstr_sender_handle_problems in prowin32 (0x004556f6) 29 0x0077d18e utgetdrv in prowin32 (0x0077d18e) 30 0x7fca75db in kernel32 (+0x475db) (0x7fca75db) 31 0xb7ee39fd (0xb7ee39fd) -----------------------------
If seen through strace, this is what happens when it hangs (I killed the wine-preloader with signal 15 to stop it in the end):
----------------------------- ... [lots of megabytes of trace, available if needed] rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\257\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\200\0\1\0\0\0\0\0\200\0\1\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\216\0\0\0\0\0\0\0\0\0\0\0T\1\1\0 \0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\200\0\0L\0\0\0\0\250\0\0\0\0\0@\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\221\0\0\0\0\0\0\0|\0\0\0T\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\301\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\221\0\0\0\0\0\0\0|\0\0\0T\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\217\0\0\0\0\0\0\0\0\0\0\0T\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0@\1\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 writev(4, [{"\241\0\0\0\n\0\0\0\0\0\0\0T\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, { "S\0y\0s\0I\0P\0", 10}], 2) = 74 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\212\0\0\0\0\0\0\0\0\0\0\0T\1\1\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(4, "\257\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\200\0\1\0\0\0\0\0\200\0\1\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ... [several megabytes of this!!] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 --- SIGTERM (Terminated) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], NULL, 8) = 0 close(7) = 0 close(8) = 0 close(5) = 0 close(4) = 0 futex(0x7fe67d3c, FUTEX_WAKE, 2147483647) = 0 exit_group(0) = ? Process 22097 detached -----------------------------
This bug is critical for me, since the program is useless if it cannot be trusted to save the information that was input through the window that fails to be destroyed
I'm not sure if this bug should be marked for Component wine-kernel, but that's my best guess.
I sorely need your help. Any thoughts/questions/tests/solutions are welcome.
Thanks!!