April 2020 - Wine-Bugs - list.winehq.org

[Bug 48883] New: Cygwin installation
by WineHQ Bugzilla Aug. 16, 2020

Aug. 16, 2020

https://bugs.winehq.org/show_bug.cgi?id=48883 Bug ID: 48883 Summary: Cygwin installation Product: Wine Version: 5.5 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: megastallman(a)gmail.com Distribution: --- Created attachment 66827 --> https://bugs.winehq.org/attachment.cgi?id=66827 wine client error:34: read: Bad file descriptor I'm trying to install 32-bit Cygwin. The installer starts, downloads tarballs, then just hangs with the "wine client error:34: read: Bad file descriptor". Wineboot doesn't help. Download link: https://cygwin.com/setup-x86.exe My current wine installation is done into a 32-bit Xubuntu18.04 chroot, where the latest wine-staging is built and used. So I can update/rebuild any time required. Doing "~/.wine", build and installation directories deletion every rebuild. The host system - is Opensuse Thumbleweed x86_64. Choot allows X11 and OpenGL throughput, e.g. - I can run glxgears. See the crashlog in attachment. -- 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.

1 11

[Bug 40958] New: Toontown Rewritten has major lag on wine-staging on FreeBSD and GNOME 3
by wine-bugs＠winehq.org Aug. 16, 2020

Aug. 16, 2020

https://bugs.winehq.org/show_bug.cgi?id=40958 Bug ID: 40958 Summary: Toontown Rewritten has major lag on wine-staging on FreeBSD and GNOME 3 Product: Wine-staging Version: 1.9.13 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: neel(a)neelc.org CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Toontown Rewritten (http://toontownrewritten.com/) has major lag with keystrokes on wine-staging when I use FreeBSD and GNOME 3. TTR is a online game, and using keyboard controls often results in the display lagging by a few seconds. Other desktop environments don't have this lag to as great of an extent (I also tested TTR on Mate and Fluxbox). Is there a reason for this? -- 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.

2 4

[Bug 45437] New: Readme' s installation instructions link leads to winehq page with no installation instructions
by wine-bugs＠winehq.org Aug. 16, 2020

Aug. 16, 2020

https://bugs.winehq.org/show_bug.cgi?id=45437 Bug ID: 45437 Summary: Readme's installation instructions link leads to winehq page with no installation instructions Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: root(a)swooshalicio.us CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- The readme in the wine-staging repository links to https://wine-staging.com/installation.html which redirects to https://wiki.winehq.org/Wine-Staging which contains no information for installing wine-staging. -- 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.

2 3

[Bug 48188] New: wine fails to load, "kernelbase.dll" failed to initialize, aborting
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48188 Bug ID: 48188 Summary: wine fails to load, "kernelbase.dll" failed to initialize, aborting Product: Wine Version: 4.20 Hardware: x86 OS: Linux Status: NEW Keywords: download, regression Severity: critical Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: julliard(a)winehq.org Distribution: --- 000b:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 000b:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 d05c9f12fb9409e2bc65bb59fa596c9872915d40 is the first bad commit commit d05c9f12fb9409e2bc65bb59fa596c9872915d40 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Nov 27 09:54:51 2019 +0100 kernelbase: Initialize codepage data using ntdll functions. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> :040000 040000 46104b3961726d8c6d83abb04a7619008d88aad1 bedb6cb4be88dc3711d75909d60ca4d89dfb6702 M dlls mingw is enabled: austin(a)laptop ~/wine-git ((no branch, bisect started on master)) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/9.2.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /var/tmp/portage/cross-i686-w64-mingw32/gcc-9.2.0-r2/work/gcc-9.2.0/configure --host=x86_64-pc-linux-gnu --target=i686-w64-mingw32 --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/i686-w64-mingw32/gcc-bin/9.2.0 --includedir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include --datadir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0 --mandir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/man --infodir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include/g++-v9 --with-python-dir=/share/gcc-data/i686-w64-mingw32/9.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0-r2 p3' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/i686-w64-mingw32 --disable-bootstrap --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgomp --disable-libmudflap --disable-systemtap --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: win32 gcc version 9.2.0 (Gentoo 9.2.0-r2 p3) -- 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.

1 4

[Bug 46047] New: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress , kernel32.dll.WakeByAddress{All,Single} (VLC)
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=46047 Bug ID: 46047 Summary: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress, kernel32.dll.WakeByAddress{All,Single} (VLC) Product: Wine Version: 3.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track: * https://www.winehq.org/pipermail/wine-devel/2018-October/134085.html * https://www.winehq.org/pipermail/wine-devel/2018-October/134086.html There is a series of articles on the background/inner workings of this Windows 8+ futex-like operations by Raymond Chen on Microsoft developer blog "The Old New Thing": (1) https://blogs.msdn.microsoft.com/oldnewthing/20160823-00/?p=94145 ("WaitOnAddress lets you create a synchronization object out of any data variable, even a byte") (2) https://blogs.msdn.microsoft.com/oldnewthing/20160824-00/?p=94155 ("Implementing a synchronization barrier in terms of WaitOnAddress") (3) https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=94165 ("Implementing a critical section in terms of WaitOnAddress") (4) https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185 ("Spurious wakes, race conditions, and bogus FIFO claims: A peek behind the curtain of WaitOnAddress") Alternative overview to the blog using Github-based WIKI: https://github.com/mity/mctrl/wiki/Old-New-Win32API (click the sections to get to blog entries) WaitOnAddress() * WaitOnAddress lets you create a synchronization object out of any data variable, even a byte * Implementing a synchronization barrier in terms of WaitOnAddress * Implementing a critical section in terms of WaitOnAddress * Extending our critical section based on WaitOnAddress to support timeouts * Comparing WaitOnAddress with futexes (futexi? futexen?) * Creating a semaphore from WaitOnAddress * Creating a semaphore with a maximum count from WaitOnAddress * Creating a manual-reset event from WaitOnAddress * Creating an automatic-reset event from WaitOnAddress Related: bug 45524 ("Add a futex-based implementation of condition variables") I found multiple applications which make use of this Windows 8+ API. Example: VLC https://github.com/videolan/vlc/blob/master/src/win32/thread.c Most of them have fallback implementations if the API is not available so it's not critical to the functionality. But it's still good to have real world tests :-) Regards -- 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.

2 10

[Bug 48798] New: RegCloseKey: Uninitialized read from get_language_sort
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48798 Bug ID: 48798 Summary: RegCloseKey: Uninitialized read from get_language_sort Product: Wine Version: 5.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: jeffersoncarpenter2(a)gmail.com Distribution: --- Created attachment 66710 --> https://bugs.winehq.org/attachment.cgi?id=66710 Configure output. Steps to reproduce: * Build wine 5.3 (or commit 00e55c8fc0). Configure output attached. * Disable wine preloader to make valgrind a little quieter. * Compile a test program (I used 'int main() { return 0; }') using i686-w64-mingw32-gcc * Run this under valgrind. Valgrind output attached. The first error raised by valgrind is: ==9987== Conditional jump or move depends on uninitialised value(s) ==9987== at 0x7B062414: RegCloseKey (registry.c:965) ==9987== by 0x7B040070: get_language_sort (locale.c:693) ==9987== by 0x7B040243: init_locale (locale.c:737) ==9987== by 0x7B04BE43: DllMain (main.c:48) ==9987== ... The uninitialized value is the HKEY key defined in get_language_sort. -- 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.

1 9

[Bug 47766] New: PathAllocCanonicalize treats path segments start with dots wrong.
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=47766 Bug ID: 47766 Summary: PathAllocCanonicalize treats path segments start with dots wrong. Product: Wine Version: 4.16 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: zzhang(a)codeweavers.com Distribution: --- This bug was reported on wine-devel mail list by Sebastian M. Ernst <ernst(a)pleiszenburg.de> user(a)comp:/path/other> WINEDEBUG=-all PYTHONHOME="z:\\path\\.to\\target" wine /path/.to/target/python.exe -c "import sys; print(sys.executable)" Z:\pathto\target\python.exe PYTHONHOME="z:\\path\\..to\\target" wine /path/..to/target/python.exe -c "import sys; print(sys.executable)" Z:\to\target\python.exe -- 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.

1 9

[Bug 48942] New: stack overflow on startup
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48942 Bug ID: 48942 Summary: stack overflow on startup Product: Wine Version: 5.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: triffid.hunter(a)gmail.com Distribution: --- Created attachment 66917 --> https://bugs.winehq.org/attachment.cgi?id=66917 strace -s 1024 -f wine -- notepad $ wine notepad 000b:err:seh:setup_exception stack overflow 464 bytes in thread 000b eip 000000007bcbdb9a esp 0000000000131440 stack 0x130000-0x131000-0x230000 0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\notepad.exe" failed, status c0000005 $ wine --version wine-5.6 Wine-5.4 worked fine. I've also attached an strace in case it's helpful. I'm installing wine-5.5 to test for regression. There's another report at https://www.reddit.com/r/openSUSE/comments/g14xvn/wine_issues_after_fresh_i… which seems related although the exact numbers are different. -- 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.

1 10

[Bug 48542] New: Mono (and probably .NET) needs CreateThreadpoolIo
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48542 Bug ID: 48542 Summary: Mono (and probably .NET) needs CreateThreadpoolIo Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Distribution: --- Found testing LiveSplit 1.7.7 on Wine Mono from the master branch. Mono's implementation of System.Threading.ThreadPoolBoundHandle depends on CreateThreadpoolIo. Wine's stub of this function returns 0 and doesn't set last error, resulting in the confusing message "System.IO.IOException: Success". This can be more easily reproduced by running 'make test' in Wine Mono and running tests/run-tests.exe MonoTests.System.IO.Pipes.PipeSecurityTest:NamedPipePermissionsActuallyWorkAsync -- 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.

1 8

[Bug 48471] New: Mismatching behavior of GetEnvironmentVariableW for empty / long values
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48471 Bug ID: 48471 Summary: Mismatching behavior of GetEnvironmentVariableW for empty / long values Product: Wine Version: 5.0-rc4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: wine(a)thecybershadow.net Distribution: --- Attempting to build the Windows version of DMD, the reference compiler for the D programming language, fails under Wine. This seems to be caused by the following chain of events: 1. The makefile invokes a build program with a "VERBOSE=" on the command-line: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… (Here "$(VERBOSE)" is not set and expands to the empty string.) 2. The build program registers the command-line arguments into the process environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… This sets the environment variable VERBOSE to the empty string. 3. Later, it attempts to check if the "VERBOSE" variable is in the environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… 4. This calls the following Windows code in the standard library to read the environment: https://github.com/dlang/phobos/blob/e373b4e77448bc11c6e4ea6c85bcdb8f7ab86f… 5. For empty variables, the code behaves differently in Windows and Wine - Wine's implementation returns 0, while Windows returns 1. As a result, the standard library code throws an exception under Wine. Writing a test program reveals further differences. The program: #include <stdio.h> #include <windows.h> void main() { WCHAR buf[4]; DWORD size; int len, i; for (len = 0; len <= 2; len++) { for (i = 0; i < len; i++) buf[i] = 'a'; buf[len] = 0; SetEnvironmentVariableW(L"TESTVAR", buf); for (i = 0; i <= len + 1; i++) { DWORD err; SetLastError(1); buf[0] = 1; size = GetEnvironmentVariableW(L"TESTVAR", buf, i); err = GetLastError(); printf("%d->%d: size=%d error=%d buf[0]=%d\n", len, i, size, err, buf[0]); } printf("\n"); } } Output on Windows [Version 10.0.17134.648]: 0->0: size=1 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=1 buf[0]=1 1->1: size=2 error=1 buf[0]=0 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=1 buf[0]=1 2->1: size=3 error=1 buf[0]=0 2->2: size=3 error=1 buf[0]=0 2->3: size=2 error=1 buf[0]=97 Output on Wine: 0->0: size=0 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=122 buf[0]=1 1->1: size=2 error=122 buf[0]=1 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=122 buf[0]=1 2->1: size=3 error=122 buf[0]=1 2->2: size=3 error=122 buf[0]=1 2->3: size=2 error=1 buf[0]=97 We can observe these differences: 1. Wine returns 0 and not 1 when the variable is empty and the function is given a zero-length buffer. 2. Wine sets the last error to ERROR_INSUFFICIENT_BUFFER, while Windows doesn't. 3. Windows zeroes the buffer if the size is non-zero but still insufficient to hold the value. (This is not a bug as the behavior is specified in the documentation to be undefined.) -- 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.

1 7