Bug 1110419

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.