http://bugs.winehq.org/show_bug.cgi?id=60110 --- Comment #9 from nong24@qq.com --- (In reply to Ken Sharp from comment #7) Thanks for looking into this. To address your points: **1. hang vs crash** You're right — the app hangs, it doesn't crash/exit. The process stays alive (pgrep finds it, pkill kills it). The "Unhandled stack overflow" in the terminal output from the original report is a Wine-internal log event; the process itself doesn't terminate. So your observation of a hang matches mine. **2. ODBC** The "err:winediag:load_odbc failed to open library libodbc.so" message is a red herring. I checked: - The app's own import table does NOT import odbc32.dll. Its imports are: MFC42, MSVCRT, KERNEL32, USER32, GDI32, comdlg32, ADVAPI32, SHELL32, COMCTL32, ole32, OLEPRO32, OLEAUT32, VERSION, SETUPAPI, HID, SHLWAPI, iphlpapi, gdiplus, WS2_32. - The native mfc42.dll (required by the app) statically imports odbc32.dll. This is what causes odbc32.dll to be loaded and the winediag message to appear. - A WINEDEBUG=+loaddll,+odbc run shows odbc32.dll loaded once at startup (DllMain only), then zero SQL* function calls throughout the entire session — including at the point where the hang occurs. Installing ODBC (unixODBC or via winetricks mdac28) would only silence the winediag message; it should not change the hang. **3. Root cause: confirmed via winedbg backtrace** I ran the app under winedbg with BreakOnFirstChance enabled and caught the EXCEPTION_STACK_OVERFLOW (0xc00000fd) at first chance, before mfc42's SEH handler could intercept it. The backtrace (attached) shows unbounded re-entrant recursion through the comctl32 subclassing chain. The repeating cycle is: SetWindowTextA(hwnd, "0000") -> SendMessageA(hwnd, WM_SETTEXT) [msg=0xc] -> COMCTL32_SubclassProc -> DefSubclassProc -> TOOLTIPS_SubclassProc -> DefSubclassProc -> CallWindowProcW -> EDIT_WindowProc -> EDIT_WM_SetText -> notify_parent(EN_UPDATE) [msg=0x111] -> mfc42 WndProc -> SetWindowTextA(...) [re-enter] This cycle repeats ~140 times (each cycle consumes 7392 bytes of stack; 1MB stack exhausted at ESP=0x231ee8). The overflow triggers in WINPROC_CallProcWtoA (user32/winproc.c). The full winedbg session is attached as "winedbg_backtrace_60110.txt". Key frames from the backtrace: frame 58: SetWindowTextA(hwnd=000100C0, lpString="0000") frame 48: DefSubclassProc(uMsg=0xc) [WM_SETTEXT] frame 51: COMCTL32_SubclassProc(uMsg=0xc) frame 31: EDIT_WM_SetText frame 30: notify_parent -> SendMessageW(msg=0x111) [EN_UPDATE] frame 103: SetWindowTextA(hwnd=000100C0, lpString="0000") [re-enter] ... (repeats to frame 193, then stack overflow) **4. Conformance test (attachment 81666) — request for verification** The attached conformance test (attachment 81666) reproduces the same class of WM_SETTEXT re-entrancy without needing the app, mfc42, or ODBC. I ran it on both Wine and Windows: - Wine 11.14: recursion reaches the test's guard (depth 50) - Windows: recursion is bounded (depth ~15) I would appreciate it if you could verify the test on your Windows setup to confirm the Windows behavior independently. A note on scope: the test is a *simplified* reproduction. It triggers re-entrancy via a WndProc that re-enters SetWindowText on WM_SETTEXT, with a passive subclass in the chain. The real app's cycle (shown in the backtrace above) is more involved — it goes through EDIT_WM_SetText -> notify_parent(EN_UPDATE) -> WM_COMMAND -> mfc42 -> SetWindowText, with the comctl32 subclassing chain (TOOLTIPS_SubclassProc) in between. But both expose the same underlying gap: Wine does not bound WM_SETTEXT re-entrancy the way Windows does. The test isolates the core issue; the backtrace confirms it manifests in the real app. Notably, Wine already defines MAX_WINPROC_RECURSION (64) in dlls/win32u/message.c, but this limit did not prevent the recursion from reaching ~140 levels in the app — the re-entrancy appears to bypass the existing guard. This may warrant investigation as the potential fix site. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.