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

[Bug 29494] New: Occasional wineserver crashes when playing Warcraft 3
by wine-bugs＠winehq.org 01 Jul '20

01 Jul '20

http://bugs.winehq.org/show_bug.cgi?id=29494 Bug #: 29494 Summary: Occasional wineserver crashes when playing Warcraft 3 Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: stefan(a)codeweavers.com Classification: Unclassified During a recent LAN-Party with friends I experienced occasional wineserver crashes when playing Warcraft 3: The Frozen Throne. The crashes mostly occurred when a new Local Network game was started(Not Battle.net) but I've also seen one crash during a running game. The problem cannot be reproduced easily. It seems to be tied to my friend's network or one of the participating computers. I've also seen them a year ago with then-current wine versions. Unfortunately I could not reproduce the crashes with my own home network, and I played WC3 multiple times without any issues over the year. I've been able to generate a core dump, which I'm attaching to the bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 15

[Bug 48664] New: kernel32:process - Intermittent test_Toolhelp() failure
by WineHQ Bugzilla 30 Jun '20

30 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=48664 Bug ID: 48664 Summary: kernel32:process - Intermittent test_Toolhelp() failure Product: Wine Version: 5.2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com >From time to time kernel32:process produces the following failures: process.c:1226: Test failed: expected 1, got 0 process.c:1229: Test failed: Child process termination process.c:1233: Test failed: Toolhelp:cntUsage expected 0, but got 1 process.c:1234: Test failed: Toolhelp:th32DefaultHeapID expected 0, but got 1 process.c:1235: Test failed: Toolhelp:th32ModuleID expected 0, but got 1 process.c:1236: Test failed: Toolhelp:th32ParentProcessID expected 1860, but got 0 process.c:1238: Test failed: Toolhelp:dwFlags expected 0, but got 1 https://test.winehq.org/data/tests/kernel32:process.html These happened on fg-win7u64-1spie9* (32 and 64 bits), newtb-w7pro64-32, newtb-w864-32, newtb-w8adm, cw-gtx560-64, cw-rx460-1709-32 and cw-gtx560-1809-32 so it's not just one buggy system. The tests were introduced by this commit: commit a0b6bf86f74438c574f7165ab220060681bb66cd Author: Sebastian Lackner <sebastian(a)fds-team.de> AuthorDate: Mon Dec 21 13:06:37 2015 +0100 kernel32/tests: Add test for process object destruction. Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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 48956] New: winecfg fails to initialize kernelbase.dll
by WineHQ Bugzilla 30 Jun '20

30 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=48956 Bug ID: 48956 Summary: winecfg fails to initialize kernelbase.dll Product: Wine Version: 5.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: winecrt0 Assignee: wine-bugs(a)winehq.org Reporter: jeff(a)macloue.com Distribution: --- Created attachment 66932 --> https://bugs.winehq.org/attachment.cgi?id=66932 WINEDEBUG=+module,+nls,+file,+reg,+ntdll winecfg winecfg fails to initialize on an empty prefix, with the following message: 000d:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting Using bisect I traced the error to the following commit: commit 036f4dca3c7f9ee8964bb4ae0c4bcd106a347c7b Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Apr 8 15:09:00 2020 +0200 winecrt0: Rebuild the argv array instead of getting it from libwine. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> After studying the debug output I found that the process of kernelbase.dll initialization is strange. First time the trace output comes from 64-bit version: 000f:trace:module:MODULE_InitDLL (0x7b010000 L"kernelbase.dll",PROCESS_ATTACH,0x32fb00) - CALL 000f:trace:module:LdrGetDllHandle L"kernel32.dll" -> 0x7b420000 (load path L"C:\\windows\\system32;C:\\windows\\system32;C:\\windows\\system; 000f:trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x1004,000000000032E38C,2) 000f:trace:module:FindResourceExW 000000007B420000 #0006 #0101 0409 000f:trace:module:LoadResource 000000007B420000 000000007B4D83B0 000f:trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x1004,000000000032E38C,2) returning number 1252 000f:trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x1011,000000007B0DBBE0,2) And the second time the output looks like coming from 32-bit code: 000d:trace:module:MODULE_InitDLL (0x7b010000 L"kernelbase.dll",PROCESS_ATTACH,0x32fd24) - CALL 000d:trace:module:LdrGetDllHandle L"kernel32.dll" -> 0x7b410000 (load path L"C:\\windows\\system32;C:\\windows\\system32;C:\\windows\\system; 000d:trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x1004,0032E748,2) 000d:trace:module:FindResourceExW 7B410000 #0006 #0101 0409 000d:trace:module:LoadResource 7B410000 7B4B6EF4 000d:trace:nls:GetLocaleInfoW (lcid=0x409,lctype=0x1004,0032E748,2) returning number 1252 (note narrower integer values) Before the commit in question all the output from MODULE_InitDLL looks identical. The exact reason of initialization failure is because FILE_CreateFile() returns STATUS_OBJECT_PATH_NOT_FOUND instead of STATUS_OBJECT_NAME_NOT_FOUND when looking for sortdefault.nls: 000d:trace:ntdll:FILE_CreateFile handle=0x32e45c access=80000000 name=L"\\??\\C:\\windows\\globalization\\sorting\\sortdefault.nls" objattr=00000000 root=(nil) sec=(nil) io=0x32e3e8 alloc_size=(nil) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 000d:trace:file:wine_nt_to_unix_file_name L"\\windows\\globalization\\sorting\\sortdefault.nls" not found in /tmp/mock/dosdevices/c:/windows 000d:warn:ntdll:FILE_CreateFile L"\\??\\C:\\windows\\globalization\\sorting\\sortdefault.nls" not found (c000003a) Because of this the code in open_nls_data_file in dlls/ntdll/locale.c does not look in the WINEDATADIR for the file and returns overall failure. Compare to the previous, successful call: 000f:trace:ntdll:FILE_CreateFile handle=0x32dfb8 access=80000000 name=L"\\??\\C:\\windows\\globalization\\sorting\\sortdefault.nls" objattr=00000000 root=(nil) sec=(nil) io=0x32ded0 alloc_size=(nil) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 000f:trace:file:wine_nt_to_unix_file_name L"\\windows\\globalization\\sorting\\sortdefault.nls" not found in /tmp/mock/dosdevices/c:/windows/globalization/sorting/sortdefault.nls 000f:warn:ntdll:FILE_CreateFile L"\\??\\C:\\windows\\globalization\\sorting\\sortdefault.nls" not found (c0000034) (Note a different status code returned and that wine_nt_to_unix_file_name() looks for the file in the correct place) I was unable to find out why exactly this happens, the commit in question does not seem to touch anything that may cause the issue. winecfg works if called with "wine64 winecfg", but unfortunately running Win32 programs is not possible either with "wine" or "wine64" - failing with the same error, so I consider the bug critical. The bug can be worked around by manually copying nls/sortdefault.nls to $WINEPREFIX/drive_c/windows/globalization/sorting/ - or using wine on a prefix initialized by a working version. It does not reproduce on wine64-only install (which cannot run Win32 application by design), and though "wine64 winecfg" works - it doesn't add the windows/globalization/sorting/sortdefault.nls or other NLS files any more. The full trace log of winecfg which ends with the error is attached. -- 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 40979] New: Starcraft 2 crashes in online game.
by wine-bugs＠winehq.org 30 Jun '20

30 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=40979 Bug ID: 40979 Summary: Starcraft 2 crashes in online game. Product: Wine Version: 1.9.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vet.roland(a)gmail.com Distribution: --- When plaing starcraft, attempting to play a multiplayer game (i.e. 1v1 (un)ranked) the game freezes, needing a kill command (sigterm). Also mentioned in this thread: https://forum.winehq.org/viewtopic.php?f=8&t=27111 Attached is the log with a few amendments to indicate ingame moments. -- 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 19

[Bug 10459] New: Crash in G-Nome which uses Smacker Video Codec ( smackw32 + render.r32)
by wine-bugs＠winehq.org 30 Jun '20

30 Jun '20

http://bugs.winehq.org/show_bug.cgi?id=10459 Summary: Crash in G-Nome which uses Smacker Video Codec (smackw32 + render.r32) Product: Wine Version: 0.9.39. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: legolas558(a)email.it G-Nome is a game developed by 7thlevel. It is a quite old game (1998). The game uses the Smacker Video Codec, which seems to be the faulty one. The crash happens in the render.r32 (exact filename) DLL; there is to say that a similar crash happens on Windows XP when exiting the game. The initial video is played correctly, although when ending the "Loading mission" stage the game cannot be played. If Wine will be fixed for this Smacker Video Codec bug, many other games will get the enhancement. I am available for further testing, debugging or assembly inspection. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 16

[Bug 26226] New: msxml3 emits too much xmlns attributes
by wine-bugs＠winehq.org 30 Jun '20

30 Jun '20

http://bugs.winehq.org/show_bug.cgi?id=26226 Summary: msxml3 emits too much xmlns attributes Product: Wine Version: 1.3.14 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: marcus(a)jet.franken.de When using www.wiso-kassenbuch.de initial registration checking fails (free download: http://update.buhl-finance.com/ESD/EUER%20und%20Kasse/WISO%20EUER%20und%20K… trial code is: EUR2011TRY ) reproduce: Start the installer, enter EUR2011TRY in the field below "Ihr AKtions-Code) and press "Weiter". It will then report a "400" error in a messagebox. The program sends a SOAP request to the on4u3.buhl.de server which is not accepted by the server (likely not validating against a stylesheet). I debugged this and using native MSXML3 it works, just our msxml3 will not. I tooked a debug dump of the XML sent of both, will attach both versions. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 51

[Bug 30850] New: use-after-free error when running Gigasoft ProEssentials graph component?
by wine-bugs＠winehq.org 30 Jun '20

30 Jun '20

http://bugs.winehq.org/show_bug.cgi?id=30850 Bug #: 30850 Summary: use-after-free error when running Gigasoft ProEssentials graph component? Product: Wine Version: 1.5.5 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified A real app that uses gigasoft's graphing component is having a strange clipping problem when using gigasoft's "scientific graph" component. Their canned demo doesn't run well enough to test that component (see bug 30826), so I extracted just the part that displays a "scientific" graph. It seems to run fine, but valgrind complains about some use-after-free problems: Invalid read of size 4 at HEAP_FindFreeBlock (heap.c:1003) by RtlAllocateHeap (heap.c:1688) by init_region (region.c:485) by REGION_RegionOp (region.c:1742) by REGION_UnionRegion (region.c:2170) by CombineRgn (region.c:1366) by add_cap.isra.7 (objects.c:1227) by wide_line_segments (objects.c:1470) by wide_pen_lines (objects.c:1526) by dibdrv_LineTo (graphics.c:891) by LineTo (painting.c:242) by ??? (in /home/dank/demo100/PEGRP32E.DLL) by EnumMetaFile (metafile.c:537) by ??? (in /home/dank/demo100/PEGRP32E.DLL) This looks a lot like the warn+heap crash in bug 30826. Right-clicking on the demo and exporting it as a .wmf, then loading it in to a simple app that plays back metafiles with PlayMetaFile under valgrind shows no warnings in playback. Source, executable, and a script to install visual C++ and compile the executable are attached. To reproduce: see last few lines of demo.sh in the attached archive. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 12

[Bug 39069] New: Battle.net launcher requires multiple click to focus tabs in Openbox
by wine-bugs＠winehq.org 30 Jun '20

30 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=39069 Bug ID: 39069 Summary: Battle.net launcher requires multiple click to focus tabs in Openbox Product: Wine Version: 1.7.49 Hardware: x86 URL: http://eu.battle.net/en/ OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jerome(a)leclan.ch Distribution: ArchLinux The various game tabs of the Battle.net launcher need to be clicked twice to activate, but only in openbox. This works fine with one click in kwin. -- 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 6

[Bug 49279] New: Possible array out of bounds in mci.c
by WineHQ Bugzilla 29 Jun '20

29 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=49279 Bug ID: 49279 Summary: Possible array out of bounds in mci.c Product: Wine Version: 5.9 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal54(a)gmail.com Distribution: --- Trace can use invalid memory, because index are checked after use. ``` TRACE("Dumping cmdTbl=%d [lpTable=%p devType=%d]\n", uTbl, S_MciCmdTable[uTbl].lpTable, S_MciCmdTable[uTbl].uDevType); if (uTbl >= MAX_MCICMDTABLE || !S_MciCmdTable[uTbl].lpTable) return FALSE; ``` https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a… -- 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 1

[Bug 48781] New: midiOutShortMsg sends more than 2 bytes for Program Change
by WineHQ Bugzilla 29 Jun '20

29 Jun '20

https://bugs.winehq.org/show_bug.cgi?id=48781 Bug ID: 48781 Summary: midiOutShortMsg sends more than 2 bytes for Program Change Product: Wine Version: 5.0-rc6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: reinhold.hoffmann(a)hotmail.com Distribution: --- According to the Windows multimedia spec of midiOutShortMsg the second pair of MIDI data bytes are optional, depending on the MIDI status byte. For the MIDI event Program Change there are no optional data bytes. But midiOutShortMsg for Program Change sends those optional bytes, too. This results that some modern keyboards accepts the second byte as a further Program Change which is 0 meaning piano for bank 0. The consequence is that every midi file played by such an external MIDI device always sounds as piano. According to the Windows spec "This function - midiOutShortMsg - is used to send any MIDI message except for system-exclusive or stream messages." - which means for Program Change as well resulting in that behaviour. As a workaround midiOutLongMsg was used for Program Change with length = 2. This avoids sending additional invalid bytes. midiOutShortMsg is very broadly used according to the Windows spec for Program Change events and should be able to handle Program Change correctly. -- 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 2