March 2020 - Wine-bugs - list.winehq.org

[Bug 46670] New: Unhandled exception on Blizzard Battle.net
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=46670 Bug ID: 46670 Summary: Unhandled exception on Blizzard Battle.net Product: Wine-staging Version: 4.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: b1779506(a)trbvn.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- See attachments. -- 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 7

[Bug 44571] New: Unable to build cue sheets with IMGBurn
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=44571 Bug ID: 44571 Summary: Unable to build cue sheets with IMGBurn Product: Wine-staging Version: 3.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: halo117nachos(a)gmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 60538 --> https://bugs.winehq.org/attachment.cgi?id=60538 stderr and stdout Everytime I try to build a cue sheet out of MP3 files with IMGBurn, the program crashes. Building a cue sheet is the first step in burning MP3 (and other audio files) to standard red book audio discs, so if one can't build a cue sheet, one can't burn music. Of course, I made a new wine prefix to test this, and found that it didn't solve the problem at all. :( Here's what happens: If I click the tools menu, and select "Create Cue File... ", and I start manually adding MP3s, first the program hangs, and then it says the following: "Potential Direct Show Error! - No data has been received for 10 seconds file name: C:\blablabla\file.mp3 Decoding Progress: 9,999,999 bytes" It then gives me three options: "Cancel", "Try Again", and "Continue". BTW, that number (9,999,999) seems to very with each MP3 file. It's possible that whatever number it lands on is the end of the file. I also tend to get a more generic error, although this one is harder to reproduce. IDK if this is the same bug or not. The error is: "An error occured in the application There might be an updated version available that fixes the pr [the rest of this line seems to be cut off by some buttons on the right] Please check the website for updates - http://www.imgburn.co [once again, the message is cut off]" There are three buttons on the bottom, and three on the right (the ones on the right are the ones that cut off the text). The ones on the bottom are "send bug report", "save bug report", and "show bug report". The buttons on the right are "Continue application", "Restart application", and "Close application". If I click "Continue application", the program seems to continue working. PS: I've just run IMGBurn from the terminal, and redirected both stdout and stderr to a file, which I've attached to this report. When the aformentioned "generic" error message appeared. I tried to click "Close application", but the program froze, forcing me to kill it. That error happened on the second file. BTW, I'm running Ubuntu 16.04, and I've installed winehq-devel 3.2 from the official repositories. Also, I didn't modify the prefix at all, except to install IMGBurn, and to change the default version of Windows to XP (otherwise IMGBurn doesn't start). -- 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 9

[Bug 48410] New: The "Add syscall thunks for 64 bit" patch partly breaks USVFS
by WineHQ Bugzilla 16 Aug '20

16 Aug '20

https://bugs.winehq.org/show_bug.cgi?id=48410 Bug ID: 48410 Summary: The "Add syscall thunks for 64 bit" patch partly breaks USVFS Product: Wine-staging Version: 5.0-rc3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: qsniyg(a)mail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- This is the patch that breaks USVFS: https://github.com/wine-staging/wine-staging/blob/d36d63ac848dadbc2c8ffc933… (discussion: https://github.com/ModOrganizer2/modorganizer/issues/372) I've only tested 64-bit, so it's possible https://github.com/wine-staging/wine-staging/blob/master/patches/winebuild-… also affects it. Although USVFS works for the most part, loading DLLs fails, because LdrLoadDll (within ntdll) calls NtOpenFile (through open_dll_file), but for some reason, USVFS doesn't recognize that specific NtOpenFile call (even though it hooks other NtOpenFile calls that aren't called from ntdll without issue). I haven't looked through the patch in much detail, but from what I can tell I believe the reason why this patch breaks USVFS is because the calls to NtOpenFile from within ntdll use the direct function address, whereas with the patch, USVFS now hooks a new "wrapper" around the function, instead of the same address that ntdll calls internally. -- 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 40958] New: Toontown Rewritten has major lag on wine-staging on FreeBSD and GNOME 3
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

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 16 Aug '20

16 Aug '20

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 46047] New: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress , kernel32.dll.WakeByAddress{All,Single} (VLC)
by wine-bugs＠winehq.org 16 Aug '20

16 Aug '20

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 48188] New: wine fails to load, "kernelbase.dll" failed to initialize, aborting
by WineHQ Bugzilla 16 Aug '20

16 Aug '20

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 48798] New: RegCloseKey: Uninitialized read from get_language_sort
by WineHQ Bugzilla 16 Aug '20

16 Aug '20

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 16 Aug '20

16 Aug '20

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 48542] New: Mono (and probably .NET) needs CreateThreadpoolIo
by WineHQ Bugzilla 16 Aug '20

16 Aug '20

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