http://bugs.winehq.org/show_bug.cgi?id=13411
Summary: setup_exception_record stack overflow in Teach2000 Product: Wine Version: 1.0-rc2 Platform: PC URL: http://teach2000.memtrain.com OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: teach2000@basement.nl
If I close the Space Invaders Game of Teach2000 in a certain way, Wine crashes.
Steps: Install and run Teach2000 from http://teach2000.memtrain.com
Open a list (ex. C:\Program Files\Teach2000\Examples\Klingon - every day phrases.t2k)
Go to the 'Test' tab and select type 'Space invaders - the game'.
The game starts, after you press 'Play'.
Close the window by clicking on the red cross in the caption bar.
Exp: The window is closed.
Act: Wine hangs after hundreds of access violations.
If I close the window with 'Stop', 'Exit', only one access violation comes by. Tested on OpenSuse 10.2, Teach2000 version 8.25.
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #1 from bas teach2000@basement.nl 2008-05-25 03:42:20 --- In order to open a file, this command must be given to read xml ducuments:
wget http://kegel.com/wine/winetricks && sh winetricks riched20 msxml3
http://bugs.winehq.org/show_bug.cgi?id=13411
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=13411
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from Austin English austinenglish@gmail.com 2008-12-18 13:17:04 --- Still present in git:
http://www.digischool.nl/teach2000/teach825.exe
http://bugs.winehq.org/show_bug.cgi?id=13411
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #3 from Anastasius Focht focht@gmx.net 2008-12-18 17:11:14 --- Hello,
you only need a clean WINEPREFIX and msxml4 as prerequisite.
sh winetricks msxml4
---
The app is delphi 6/7 based, making heavy use of the TNT UnicodeControls toolkit which adds unicode capability for the standard VCL controls.
The crash happens while destroying an MDI child form as outlined in steps from comment #1
In the destroy message handler, the window/control text gets retrieved from (subclassed) controls.
First, the text length is determined by sending WM_GETTEXTLENGTH message. Then a buffer is allocated with determined length and lastly the control text is captured into buffer. Unfortunately that doesn't work out as expected ...
--- snip --- ... 0009:Call window proc 0xdf0d99 (hwnd=0x1011c,msg=WM_DESTROY,wp=00000000,lp=00000000) 0009:Call user32.SendMessageA(0001011c,0000000e,00000000,00000000) ret=004d1be0 0009:Call hook proc 0x580390 (id=WH_CALLWNDPROC,code=0,wp=00000001,lp=0032da94) 0009:Call user32.CallNextHookEx(00010046,00000000,00000001,0032da94) ret=0058040d 0009:Ret user32.CallNextHookEx() retval=00000000 ret=0058040d 0009:Ret hook proc 0x580390 (id=WH_CALLWNDPROC,code=0,wp=00000001,lp=0032da94) retval=00000000 0009:trace:msg:WINPROC_CallProcAtoW (hwnd=0x1011c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call window proc 0xdf0d8c (hwnd=0x1011c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Call user32.CallWindowProcW(00df0d99,0001011c,0000000e,00000000,00000000) ret=004d1851 0009:Call window proc 0xdf0d99 (hwnd=0x1011c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 0009:Ret window proc 0xdf0d99 (hwnd=0x1011c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.CallWindowProcW() retval=00000000 ret=004d1851 0009:Ret window proc 0xdf0d8c (hwnd=0x1011c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000000 0009:Call window proc 0xdf0d8c (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) 0009:Call user32.CallWindowProcW(00df0d99,0001011c,0000000d,00000001,0032d4fc) ret=004d1851 0009:Call window proc 0xdf0d99 (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) 0009:Call user32.CallWindowProcA(00df0d7f,0001011c,0000000d,00000001,0032d4fc) ret=00471ecc 0009:Call window proc 0xdf0d7f (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) 0009:Call user32.CallWindowProcW(60650fb2,0001011c,0000000d,00000001,0032d4fc) ret=004d1a55 0009:Call window proc 0x60650fb2 (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) 0009:Call user32.GetWindowLongW(0001011c,00000000) ret=60650fd7 0009:Ret user32.GetWindowLongW() retval=001ca680 ret=60650fd7 0009:trace:statusbar:StatusWindowProc hwnd=0x1011c msg=d wparam=1 lparam=32d4fc 0009:trace:statusbar:STATUSBAR_WMGetText 0009:Ret window proc 0x60650fb2 (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) retval=ffffffff 0009:Ret user32.CallWindowProcW() retval=ffffffff ret=004d1a55 0009:Ret window proc 0xdf0d7f (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) retval=ffffffff 0009:Ret user32.CallWindowProcA() retval=ffffffff ret=00471ecc 0009:Ret window proc 0xdf0d99 (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) retval=ffffffff 0009:Ret user32.CallWindowProcW() retval=ffffffff ret=004d1851 0009:Ret window proc 0xdf0d8c (hwnd=0x1011c,msg=WM_GETTEXT,wp=00000001,lp=0032d4fc) retval=ffffffff 0009:Ret user32.SendMessageA() retval=7fffffff ret=004d1be0 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x40e5ed 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=00000000 0009:trace:seh:raise_exception eax=00000000 ebx=80000004 ecx=00000000 edx=7fffffff esi=7fffffff edi=0032de08 0009:trace:seh:raise_exception ebp=0032dd50 esp=0032dc10 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210246 ... 0009:Call oleaut32.SysAllocStringLen(0032c658 L"Access violation at address 0040E5ED in module 'Teach2000.exe'. Write of address 00000000",00000059) ret=00405cc0 --- snip ---
The user control exhibiting the problem: a TTntStatusBar statusbar (unicode) control, subclassed from standard VCL one
--- snip --- 0009:Call user32.CreateWindowExW(00000000,001b89c4 L"TTntStatusBar.UnicodeClass",00000000,44000001,00000000,00000246,000004e4,00000013,0002010e,00000000,00400000,00000000) ret=00408e54 0009:trace:win:WIN_CreateWindowEx (null) L"TTntStatusBar.UnicodeClass" ex=00000000 style=44000001 0,582 1252x19 parent=0x2010e menu=(nil) inst=0x400000 params=(nil) 0009:trace:win:dump_window_styles style: WS_CHILD WS_CLIPSIBLINGS 00000001 0009:trace:win:dump_window_styles exstyle: 0009:trace:win:WIN_SetWindowLong 0x1011c -12 0 W --- snip ---
If you look at the return value from last SendMessage() call before the exception, 0x7fffffff is returned. This value ought to be the control text length which is obviously wrong. The VCL allocator can't allocate such a huge amount of memory, resulting in internal access violation.
The WM_GETTEXTLENGTH retrieval through default handlers in WINPROC_CallProcAtoW is correct, the result (text length) has to be zero for this control.
But the following code is somewhat buggy...
Even with zero length determined, WM_GETTEXT gets called. The (l)results from callback/SendMessage - which might be negative(!) - are passed unchecked to RtlUnicodeToMultiByteSize() which happily calculates incorrect length. That's what this delphi app stumbles about.
--- dlls/user32/wndproc.c snip --- LRESULT WINPROC_CallProcAtoW( winproc_callback_t callback, HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, LRESULT *result, void *arg, enum wm_char_mapping mapping ) {
... case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: ret = callback( hwnd, msg, wParam, lParam, result, arg ); if (*result >= 0) { WCHAR *ptr, buffer[512]; LRESULT tmp; DWORD len = *result + 1; /* Determine respective GETTEXT message */ UINT msgGetText = (msg == WM_GETTEXTLENGTH) ? WM_GETTEXT : ((msg == CB_GETLBTEXTLEN) ? CB_GETLBTEXT : LB_GETTEXT); /* wParam differs between the messages */ WPARAM wp = (msg == WM_GETTEXTLENGTH) ? len : wParam;
if (!(ptr = get_buffer( buffer, sizeof(buffer), len * sizeof(WCHAR) ))) break;
if (callback == call_window_proc) /* FIXME: hack */ callback( hwnd, msgGetText, wp, (LPARAM)ptr, &tmp, arg ); else tmp = SendMessageW( hwnd, msgGetText, wp, (LPARAM)ptr ); RtlUnicodeToMultiByteSize( &len, ptr, tmp * sizeof(WCHAR) ); *result = len; free_buffer( buffer, ptr ); } break;
... } --- dlls/user32/wndproc.c snip ---
Either skip the text retrieval for length == 0 (whats the reason anyway?) or check the return value from XX_GETTEXT before determining the byte buffer length.
I already verified with a patch, the app doesn't crash then.
Regards
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #4 from bas teach2000@basement.nl 2008-12-19 13:08:17 --- Created an attachment (id=18072) --> (http://bugs.winehq.org/attachment.cgi?id=18072) Delphi executable which shows the problem
Thanks. I am amazed by this detailed description of the problem.
I attached a minimal Delphi 2007 application which has the same behavior. This is not a problem of Teach2000 but it is a problem with the StatusBar of Tnt Unicode Controls. The attachment is an empty form with only a TntStatusBar.
In the Create I set the text of the contained panes:
procedure TForm13.FormCreate(Sender: TObject); begin TntStatusBar1.Panels[0].Text := 'Test'; TntStatusBar1.Panels[1].Text := 'with'; TntStatusBar1.Panels[2].Text := 'Wine'; end;
Without this I don't get an access violation.
Steps: Open the application in the attachment. Close it.
Exp: No access violation. Act: Access violation.
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #5 from bas teach2000@basement.nl 2008-12-22 08:49:24 --- Probably bug #13813 is related to this issue.
http://bugs.winehq.org/show_bug.cgi?id=13411
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mattia.verga@tiscali.it
--- Comment #6 from Austin English austinenglish@gmail.com 2009-01-06 13:09:15 --- *** Bug 15876 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #7 from Mattia mattia.verga@tiscali.it 2009-08-21 13:40:01 --- Bug still exist in 1.1.26
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #8 from Juan Lang juan_lang@yahoo.com 2009-08-25 17:11:53 --- Created an attachment (id=23251) --> (http://bugs.winehq.org/attachment.cgi?id=23251) Patch: Return the number of characters copied in WM_GETTEXT even if the buffer is too small
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=13411
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2009-08-25 17:13:47 --- I uploaded a patch that just fixes the statusbar control, without addressing the default processing of WM_GETTEXT. Please let me know if this addresses the issue for you.
http://bugs.winehq.org/show_bug.cgi?id=13411
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #10 from Juan Lang juan_lang@yahoo.com 2009-08-25 18:39:03 --- Actually, I just tried it. I didn't need to install msxml4 with Wine 1.1.28. I didn't see an .t2k files in my installation, but I did see a crash when exiting the application without the patch applied, whereas I didn't with the patch applied. Under the assumption that this indicates the patch fixes the bug, I went ahead and sent it in. Confirmation that it works for you would be helpful, since I don't actually use the program.
http://bugs.winehq.org/show_bug.cgi?id=13411
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://teach2000.memtrain.c |http://www.digischool.nl/te |om |ach2000/teach825.exe
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2009-08-25 18:48:14 --- Sorry, my results before were with Teach2000 v8.4.1. I just confirmed the same behavior with 8.2.5, and adjusted the URL to download it. To wit:
msxml4 is necessary for Teach2000 8.2.5. The Examples directory is present in 8.2.5.
The steps to reproduce the bug do cause the bug for me (many of Access Violation dialogs), and with the attached patch applied they do not.
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #12 from bas teach2000@basement.nl 2009-08-26 02:17:31 --- Thanks for the patch.
http://bugs.winehq.org/show_bug.cgi?id=13411
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2009-08-27 10:45:19 --- Fixed by commit 390a248e0649cf5cc4c4e8a476f0747bc204c3ba.
http://bugs.winehq.org/show_bug.cgi?id=13411
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2009-08-27 10:46:56 --- Oops, meant to mark fixed.
http://bugs.winehq.org/show_bug.cgi?id=13411
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2009-09-02 14:14:25 --- Closing bugs fixed in 1.1.29.
http://bugs.winehq.org/show_bug.cgi?id=13411
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |390a248e0649cf5cc4c4e8a476f | |0747bc204c3ba Component|-unknown |comctl32
-
wine-bugs＠winehq.org