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

[Bug 49640] New: Loading certain builtin/Winelib DLLs twice may crash

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49640 Bug ID: 49640 Summary: Loading certain builtin/Winelib DLLs twice may crash Product: Wine Version: 5.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: bshanks(a)codeweavers.com Distribution: --- When certain "builtin"/Winelib DLLs/EXEs get loaded, then unloaded, then loaded again (by two calls to GetFileVersionInfoSize() for example), the second load may result in a crash. The underlying problem is that dlopen_dll() in dlls/ntdll/unix/loader.c assumes that dlopen() is returning a freshly-mapped copy of the file. POSIX doesn't guarantee this though, and if the file was already previously loaded by Wine, and relocation fixups were applied, those fixed-up headers will be still be present. map_so_dll then applies fixups again, and that's where I'm seeing the crash. In particular, when map_so_dll is building the import directory, I see that imports->Name already has the delta applied to it from the previous load. An EXE that has this problem is the "steam.exe.so" shipped with Proton, I believe since it links to a C++ library it will not be unloaded by a dlclose() call (see https://stackoverflow.com/questions/38869657/dlclose-not-unloading-so-file-…) -- 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.

July 30, 2020

[Bug 49559] winevdm.exe crashes when running 16-bit installers (non-PE build only)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49559 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |camomille.prairial(a)laposte. | |net --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- *** Bug 49628 has been marked as a duplicate of this bug. *** -- 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.

July 30, 2020

[Bug 49628] winevdm: Trying to run any 16-bit NE returns “Unhandled page fault on read access to 00008080 at address 7E452148”

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49628 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, ArchLinux doesn't currently provide PE builds of Wine and this will cause issues with winevdm. See https://bugs.winehq.org/show_bug.cgi?id=45349#c15 and bug 49559. A request has been sent to ArchLinux to ask them to consider packaging PE build of Wine in the future: https://bugs.archlinux.org/task/67317 For now, you'll have to stick with wine-devel/wine-staging 5.11 for 16-bit applications, or compile 5.13 with mingw support to get a PE build. Marking duplicate of bug 49559. Regards. *** This bug has been marked as a duplicate of bug 49559 *** -- 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.

July 30, 2020

[Bug 47731] World of Warcraft BFA Crash with error 132 Memory could not be read.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47731 LittleLunia94(a)Gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |LittleLunia94(a)Gmail.com --- Comment #29 from LittleLunia94(a)Gmail.com --- Currently have this happen constantly on lutris-5.7.5 with DXVK 1.7. It mostly happens when I take any portal, it will crash on the loading screen and from there on the game will constantly crash more and more often until I delete the GLCache and WoW Cache folders. >From there on it'll be fine again for a while until the next crash occurs and it snowballs into more and more crashes again and I have to delete the folders again. -- 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.

July 30, 2020

[Bug 49628] winevdm: Trying to run any 16-bit NE returns “Unhandled page fault on read access to 00008080 at address 7E452148”

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49628 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |major -- 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.

July 30, 2020

[Bug 49639] World of Warcraft Shadowlands (wow) has a fly screen effect

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49639 --- Comment #1 from Ker noa <blue-t(a)web.de> --- Created attachment 67841 --> https://bugs.winehq.org/attachment.cgi?id=67841 The Console Log with invalid framebuffers -- 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.

July 30, 2020

[Bug 49639] New: World of Warcraft Shadowlands (wow) has a fly screen effect

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49639 Bug ID: 49639 Summary: World of Warcraft Shadowlands (wow) has a fly screen effect Product: Wine Version: 5.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: blue-t(a)web.de Distribution: --- Created attachment 67840 --> https://bugs.winehq.org/attachment.cgi?id=67840 Graphical glitches on tower, gras and chatbox There is a slightly annoying graphical glitch with the recent wow Shadowlands Beta. If you look at the chat box or the tower in the background, also the vegetation it looks like some kind of fly screen or linen cloth is drawn on top of it. -- 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.

July 30, 2020

[Bug 45349] Multiple applications and games crash due to missing support for 64-bit syscall thunks (StreetFighter V, World of Warcraft)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=45349 --- Comment #23 from i.Dark_Templar <idarktemplar(a)mail.ru> --- (In reply to Justin King-Lacroix from comment #21) > Re comment #19: How did you build with PE support? (I'm on Debian.) Is it > more than just having mingw-w64 installed? I built it on Gentoo. First I built via crossdev crosstoolchain for x86_64-w64-mingw32 and i686-w64-mingw32. For i686 toolchain I added '--enable-threads=posix --disable-sjlj-exceptions --with-dwarf2' configure options, for x86_64 toolchain I added only '--enable-threads=posix'. Not sure if it's relevant. After building toolchain via crossdev I had following toolchain packages installed: cross-i686-w64-mingw32/binutils cross-i686-w64-mingw32/gcc cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/binutils cross-x86_64-w64-mingw32/gcc cross-x86_64-w64-mingw32/mingw64-runtime And I had following working crosscompilers since I'm building wine both 32bit and 64bit: i686-w64-mingw32-gcc i686-w64-mingw32-g++ x86_64-w64-mingw32-gcc x86_64-w64-mingw32-g++ After that I rebuilt both wine-vanilla-5.13 and wine-staging-5.13 adding '--with-mingw' configure option. wine without staging patchset is called wine-vanilla in Gentoo, btw. I also added two patches from bug #49590 and (unrelated) a rebased patch from bug #38166. When wine is built with mingw support, different libraries are built. Instead of some '*.dll.so' libraries '*.dll' libraries would be built. I might remember wrong, but I think when I built wine without mingw, I got api-ms-win-appmodel-identity-l1-1-0.dll.so, and with mingw I got only api-ms-win-appmodel-identity-l1-1-0.dll, for example. I might be wrong with this example, but if you compare wine libraries built with mingw support and without mingw support, you'll be able to find a lot of such libraries. (In reply to Justin King-Lacroix from comment #22) > Because if so, I built wine from HEAD with PE support, and SC2 has the same > crash. There might be few issues: 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet. 2) Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help. 3) You might have built wine without using mingw. Explicitly adding '--with-mingw' option should force build system to use mingw crosscompilers or output an error during configure stage if crosstoolchain doesn't work properly or not detected. 4) If you have more than one wine package installed, ensure you're using correct one. 5) Crosscompilers might have been built differently. As I wrote earlier, I added '--enable-threads=posix' besides other options because it was required for building dxvk from source, which I'm using as well. It might have affected result, it might have not. While writing this comment, I've launched blizzard app, updated SC2 and launched it successfully, so it doesn't look like crash might have been caused by an update to SC2. -- 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.

July 30, 2020

[Bug 49508] Powershell 6.* (pwsh.exe) crashes with "abnormal program termination"

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49508 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Powershell 6.* (pwsh.exe) |Powershell 6.* (pwsh.exe) |crashes at start |crashes with "abnormal |(regression) |program termination" --- Comment #5 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- It looks like this is partly fixed by https://www.winehq.org/pipermail/wine-cvs/2020-July/146782.html and https://www.winehq.org/pipermail/wine-cvs/2020-July/146783.html When I run something like "wine pwsh.exe -c ls" it doesn`t crash anymore and works fine, but when I do "wine pwsh.exe" it exits out with "abnormal termination" or something the like. Building wine with --without-mingw still makes the error go away, and program works fine as expected. I adjust title accordingly -- 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.

July 30, 2020

[Bug 45349] Multiple applications and games crash due to missing support for 64-bit syscall thunks (StreetFighter V, World of Warcraft)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=45349 --- Comment #22 from Justin King-Lacroix <justin.kinglacroix(a)gmail.com> --- Because if so, I built wine from HEAD with PE support, and SC2 has the same crash. -- 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.

July 30, 2020