Description of problem: Wine crashes with "*** stack smashing detected ***" Version-Release number of selected component (if applicable): 1.7.19 How reproducible: Happens for certain windows programs every time, for others never. Steps to Reproduce: 1. run "wine WoTLauncher.exe", for example. Actual results: Wine crashes with "*** stack smashing detected ***" Expected results: Running flawlessly like the hand-built git version from winehq.org Additional info: fedora builds wine with "-fstack-protector-strong", while the current git version of winehq.org builds without that GCC option. compare: https://kojipkgs.fedoraproject.org//packages/wine/1.7.19/1.fc20/data/logs/i686/build.log this leads to false "stack smashing detected" program aborts, because wine actually has to mess with stack memory in order to make windows executables run. I have confirmed that when building vanilla git wine with CFLAGS="-fstack-protector-strong" the same errors occur, and with CFLAGS="" everything works.
By the way, I'm not saying this is not a wine bug; being incompatible with stack protection may as well be a bug. However, functionality-wise this is a regression, because known-to-work software stops working.
Is this 'new' for you as of .19?
(In reply to Andreas Bierfert from comment #2) > Is this 'new' for you as of .19? I have only been able to test it with .19, since both my FC19 and my FC20 are on .19 now; however, I have been able to verify that the current wine-git version works *without* -fstack-protector-strong, but doesn't with. So this error occured when switching from FC19 to FC20, which didn't increase the wine version. This seems to be a FC20-related issue. Compare https://bugzilla.redhat.com/show_bug.cgi?id=978763 and https://fedorahosted.org/fesco/ticket/1128
*** stack smashing detected ***: .wine/drive_c/Program Files/Adobe/Reader 10.0/Reader/AcroRd32.exe terminated wine-core-1.7.34-2.fc21.i686
I've spent much of the afternoon trying to debug this to no avail. Closest I got is that perhaps it is in this function: MSVCRT_wint_t CDECL MSVCRT__fputwc_nolock(MSVCRT_wint_t wc, MSVCRT_FILE* file) { MSVCRT_wchar_t mwc=wc; ioinfo *fdinfo; MSVCRT_wint_t ret; fdinfo = get_ioinfo_nolock(file->_file); if((fdinfo->wxflag&WX_TEXT) && !(fdinfo->exflag&(EF_UTF8|EF_UTF16))) { char buf[MSVCRT_MB_LEN_MAX]; int char_len; char_len = MSVCRT_wctomb(buf, mwc); if(char_len!=-1 && MSVCRT__fwrite_nolock(buf, char_len, 1, file)==1) ret = wc; else ret = MSVCRT_WEOF; }else if(MSVCRT__fwrite_nolock(&mwc, sizeof(mwc), 1, file) == 1) { ret = wc; }else { ret = MSVCRT_WEOF; } return ret; } or something it calls. But too many problems with running gdb/winedbg have prevented me from getting any further.
This is a wild guess since I haven't run into this and don't have a means to reproduce it, but Orion, could you try adding a length check on char_len? char_len = MSVCRT_wctomb(buf, mwc); + if ( char_len > MSVCRT_MB_LEN_MAX ) + char_len = MSVCRT_MB_LEN_MAX;
I'll try that. WINEDEBUG=all seems to reveal: 34302.752:0009:trace:msvcrt:MSVCRT__isatty :fd (1) 34302.752:0009:trace:msvcrt:pf_printf_w Format is: L"\3577\6000\357e\6000\1150\773b\3b74j\ce24i" 34302.752:0009:trace:msvcrt:_lock (29) 34302.752:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000042): returning 0x139b08 34302.752:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,0000013f): returning 0x112d08 34302.753:000d:trace:file:wine_nt_to_unix_file_name L"\\windows\\system\\%1.dll" not found in /export/home/orion/.wine/dosdevices/c:/windows/system 34302.753:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x112d08): returning TRUE 34302.753:000d:warn:ntdll:NtQueryAttributesFile L"\\??\\C:\\windows\\system\\%1.dll" not found (c0000034) 34302.753:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x139b08): returning TRUE 34302.753:000d:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\%1.dll",0x34f650,(nil),(nil)) 34302.753:000d:trace:file:RtlGetFullPathName_U (L"C:\\windows\\%1.dll" 520 0x34f404 (nil)) 34302.753:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000034): returning 0x139a08 34302.754:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000138): returning 0x129f10 34302.754:000d:trace:file:wine_nt_to_unix_file_name L"\\windows\\%1.dll" not found in /export/home/orion/.wine/dosdevices/c:/windows 34302.754:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x129f10): returning TRUE 34302.754:000d:warn:ntdll:NtQueryAttributesFile L"\\??\\C:\\windows\\%1.dll" not found (c0000034) 34302.754:000d:trace:heap:RtlFreeHeap (0x110000,70000062,0x139a08): returning TRUE 34302.755:000d:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\system32\\%1.dll",0x34f650,(nil),(nil)) 34302.755:000d:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\%1.dll" 520 0x34f404 (nil)) 34302.755:000d:trace:heap:RtlAllocateHeap (0x110000,70000062,00000046): returning 0x112e58 34302.755:0009:trace:seh:raise_exception code=80000101 flags=1 addr=0xf774abf0 ip=f774abf0 tid=0009
So, this is odd. I rebuilt with this patch: char_len = MSVCRT_wctomb(buf, mwc); + if(char_len>MSVCRT_MB_LEN_MAX) { + char_len = MSVCRT_MB_LEN_MAX; + TRACE("char_len = %d\n", char_len); + } + and Adobe starts up okay now. But I would have expected to see a message about char_len in the debug trace if this was actually doing anything, but I don't.
Marcus, I've created a F21 scratch build with the changes in comment 8. http://koji.fedoraproject.org/koji/taskinfo?taskID=8704233 Could you install these packages and test your app?
I figured out why I wasn't seeing any messages - I also had the following: --- wine-1.7.34/dlls/msvcrt/msvcrt.h.buf 2015-01-09 12:48:24.000000000 -0700 +++ wine-1.7.34/dlls/msvcrt/msvcrt.h 2015-01-22 12:06:11.800307738 -0700 @@ -47,7 +47,7 @@ #define MSVCRT_I64_MAX (((__int64)0x7fffffff << 32) | 0xffffffff) #define MSVCRT_I64_MIN (-MSVCRT_I64_MAX-1) #define MSVCRT_UI64_MAX (((unsigned __int64)0xffffffff << 32) | 0xffffffff) -#define MSVCRT_MB_LEN_MAX 2 +#define MSVCRT_MB_LEN_MAX 6 #ifdef _WIN64 #define MSVCRT_SIZE_MAX MSVCRT_UI64_MAX #else Which I thought I had tested, but that was before I realized that Adobe Reader was a 32-bit application. I made that change because of this code: INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch ) { return MSVCRT__wctomb_l(dst, ch, NULL); } int CDECL MSVCRT__wctomb_l(char *dst, MSVCRT_wchar_t ch, MSVCRT__locale_t locale) { int len; MSVCRT__wctomb_s_l(&len, dst, dst ? 6 : 0, ch, locale); return len; } which seems to indicate that MSVCRT_wctomb() expects a buffer of length 6. Looks like that should use MSVCRT_MB_LEN_MAX instead of "6". I reported my proposed fix upstream (see linked bug). I'll note that when I reverted the above change but kept the trace - the crash returned and I didn't see any messages, so perhaps the location was elsewhere.
Created attachment 983453 [details] wine buf patch
(In reply to Michael Cronenworth from comment #9) > I've created a F21 scratch build with the changes in comment 8. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=8704233 It still crashes with WoT launcher ;-(
Karel - can you test http://koji.fedoraproject.org/koji/taskinfo?taskID=8818633
Here's a F20 scratch build if the F21 packages are not installable. http://koji.fedoraproject.org/koji/taskinfo?taskID=8819056
I can test later this week (I'm out of my office now).
(In reply to Orion Poplawski from comment #13) > Karel - can you test > http://koji.fedoraproject.org/koji/taskinfo?taskID=8818633 Your wine-1.7.35-3 works as expected. Thanks!
wine-1.7.36-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/wine-1.7.36-1.fc21
wine-1.7.36-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/wine-1.7.36-1.fc20
Package wine-1.7.36-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wine-1.7.36-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1896/wine-1.7.36-1.fc20 then log in and leave karma (feedback).
wine-1.7.36-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
wine-1.7.39-1.fc20, wine-mono-4.5.6-1.fc20, mingw-wine-gecko-2.36-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.