July 2023 - Wine-bugs - list.winehq.org

[Bug 53806] New: Archicad 26: crash at launch
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=53806 Bug ID: 53806 Summary: Archicad 26: crash at launch Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: doubleboogieblues(a)yahoo.it Distribution: --- Created attachment 73316 --> https://bugs.winehq.org/attachment.cgi?id=73316 terminal output Wine crash when launched archicad.exe installation ok, but the software does not start installed: dotnet452, vcrun2019, vcrun2013 download DEMO Archicad 26: https://graphisoft.com/dl/AC/26/INT/Archicad-26-INT-3001-1.1.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 6

[Bug 55346] New: ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55346 Bug ID: 55346 Summary: ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine: ddraw2.c:3237: Test failed: Got unexpected screen size 320x240. ddraw2.c:3243: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3292: Test marked flaky: Expected message 0x46, but didn't receive it. ddraw2.c:3295: Test marked flaky: Expected screen size 1024x768, got 0x0. ddraw2.c:3302: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). [the messages above don't always happen] ddraw2.c:3326: Test failed: Expected surface width 1024, got 320. ddraw2.c:3328: Test failed: Expected surface height 768, got 240. ddraw2.c:3333: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3341: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3346: Test failed: Expected surface width 1024, got 320. ddraw2.c:3348: Test failed: Expected surface height 768, got 240. ddraw2.c:3361: Test failed: Expected surface width 1024, got 320. ddraw2.c:3363: Test failed: Expected surface height 768, got 240. ddraw2.c:3368: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3384: Test marked todo: Got unexpected hr 0. ddraw2.c:3392: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3412: Test failed: Got unexpected hr 0. ddraw2.c:3414: Test failed: Got unexpected hr 0. ddraw2.c:3422: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3427: Test failed: Expected surface width 1024, got 320. ddraw2.c:3429: Test failed: Expected surface height 768, got 240. ddraw2.c:3449: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3464: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3470: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3483: Test failed: Expected resolution 1024x768, got 320x240. ddraw2.c:3500: Test failed: Expected surface width 1024, got 320. ddraw2.c:3502: Test failed: Expected surface height 768, got 240. ddraw2.c:3507: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3518: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3523: Test failed: Expected surface width 1024, got 320. ddraw2.c:3525: Test failed: Expected surface height 768, got 240. ddraw2.c:3538: Test failed: Expected surface width 1024, got 320. ddraw2.c:3540: Test failed: Expected surface height 768, got 240. ddraw2.c:3545: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3561: Test marked todo: Got unexpected hr 0. ddraw2.c:3569: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3582: Test failed: Got unexpected hr 0. ddraw2.c:3584: Test failed: Got unexpected hr 0. ddraw2.c:3592: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3597: Test failed: Expected surface width 1024, got 320. ddraw2.c:3599: Test failed: Expected surface height 768, got 240. ddraw2.c:3619: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3634: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3640: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3653: Test failed: Expected resolution 1024x768, got 320x240. ddraw2.c:3670: Test failed: Expected surface width 1024, got 320. ddraw2.c:3672: Test failed: Expected surface height 768, got 240. ddraw2.c:3678: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3695: Test failed: Expected message 0x5, but didn't receive it. ddraw2.c:3697: Test failed: Expected screen size 1024x768, got 0x0. ddraw2.c:3704: Test failed: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3716: Test failed: Expected surface width 1024, got 320. ddraw2.c:3718: Test failed: Expected surface height 768, got 240. ddraw2.c:3765: Test failed: Expected message 0x47, but didn't receive it. ddraw2.c:3769: Test failed: Expected screen size 2 1024x768, got 0x0. ddraw2.c:3777: Test failed: Expected (0,0)-(1024,768), got (0,0)-(119,100). ddraw2.c:3789: Test failed: Expected surface width 1024, got 320. ddraw2.c:3791: Test failed: Expected surface height 768, got 240. See https://test.winehq.org/data/patterns.html#ddraw:ddraw2 Where 0x46 == WM_WINDOWPOSCHANGING 0x7e == WM_DISPLAYCHANGE Both the expected and unexpected resolutions change from one run to the next: 1024x768 / 320x240 like here or 3840x2160 / 640x480 or 640x480 / 720x480 or 1024x768 / 640x480 or 1024x768 / 400x300. Note that these WineTest reports have no prior test failure. There are not too many instances of this in the nightly tests besides the rbernon-* machines where it happens regularly. However it can also happen for merge requests (3 known cases but there may be more): * 2023-07-26 MR3413 * 2023-06-15 gitlab-debian-32 * 2023-05-12 MR2792 * 2023-02-22 fg-deb64-t32 * 2022-11-29 fgtb-debian11-win32 * 2022-11-28 MR1561 -- 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 55232] New: Sierra Chart (All versions): Out of order overlapped network I/O receive buffers
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55232 Bug ID: 55232 Summary: Sierra Chart (All versions): Out of order overlapped network I/O receive buffers Product: Wine Version: 6.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: sc(a)sierrachart.com Distribution: --- Created attachment 74837 --> https://bugs.winehq.org/attachment.cgi?id=74837 Terminal output We have a code which is working fine for years on Windows OS, but on Linux using Wine it produces an IO error. Investigation shows that IO Completion/Overlapped of Wine provides some buffers with received data out of order. Our code relies on correct order of the received buffers. Our code provides to OS some minimum number of buffers available to receive a data. We expect the FIFO logic of the buffer processing: the first provided available buffer will first receive the data. Invoke `WSARecv` with a buffer to receive data. The operation is overlapped using Completion Port. In a worker thread the function `GetQueuedCompletionStatus` is used to get the completion notification about received data in the buffer. At this point we observe a buffer, received out of order. Usually it is happened at beginning of handling buffers: we provide to OS some set of buffers (in common 16), handle all of them with received data, reuse available buffers again to OS to support the minimum set of buffers for OS and most probably the first (or close to first) reused buffer will be received out of the order. Also we observe the out-of-order buffer is returned in the same time slot as it was issued to OS. Relevant WindowsOS functions used: CreateIoCompletionPort WSARecv GetQueuedCompletionStatus Download link: https://www.sierrachart.com/downloads/ZipFiles/SierraChart2522.zip -- 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

[Bug 55365] New: ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55365 Bug ID: 55365 Summary: ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine: file.c:1320: Test failed: [ffsi] CallerAvailableAllocationUnits error fsi:0x12dbfb5, ffsi: 0x12dbfb6 See https://test.winehq.org/data/patterns.html#ntdll:file This is very rare as there are only 3 known instances: * 2023-03-27 linux_gitlab-debian-32 * 2023-06-23 linux_gitlab-debian-32 * 2023-07-27 win21H2_gitlab-win10-21h2-64 This looks very much like a race condition with some other process allocating or freeing disk space in between the FileFsFullSizeInformation and FileFsSizeInformation calls. So this is something that should be fixable with the tryok() API. https://gitlab.winehq.org/wine/wine/-/merge_requests/3418 -- 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 55363] New: Wine depends on a manual user intervention to increase the soft limit of file descriptors.
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55363 Bug ID: 55363 Summary: Wine depends on a manual user intervention to increase the soft limit of file descriptors. Product: Wine Version: 8.11 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be Distribution: --- Hello, I recently installed Debian 12 after using Debian 8 for years. After I reproduced my building environment and successfully build the same Wine version as the last built on Debian 8, a game that was working fine in Debian 8 did fail to run on Debian 12 with the error 'too many file descriptors open, you should probably increase ulimit -n'. The difference is that the default soft/hard limit in Debian 12 is 1024/1048576. In Debian 8 it was 65536/65536. I can increase the soft limit by running 'ulimit -n 65536' before hand and then the game runs fine. I could not set the soft limit increase to be permanent and I filed a bug at Debian for that, but that's not what this bug is about. After reading a bit about the reason why the soft limit was reduced to 1024 (for compatibility with select()), my understanding is that a program that is more modern and doesn't use select(), should be aware of its file descriptor needs and ask for a higher soft limit. That's what Debian says about its choice to set the soft limit of 1024 and a hard limit of 1048576 by default. Since the hard limit permits it, I wondered why Wine couldn't increase the soft limit itself. We know that 1024 is not a reasonable amount of file descriptors in this time and day and that a number of windows applications requires more than that. Maybe Wine should set the soft limit to something reasonable itself, rather than requiring the user to set it like explained in the FAQ? It would even be better if it was configurable per-application. 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.

1 2

[Bug 55324] New: AllDup doesn't start in win10 mode: "OS not supported"
by WineHQ Bugzilla 29 Jul '23

29 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55324 Bug ID: 55324 Summary: AllDup doesn't start in win10 mode: "OS not supported" Product: Wine Version: 8.13 Hardware: x86-64 URL: https://www.alldup.info/download/AllDupSetup.zip OS: Linux Status: NEW Keywords: download, patch Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Created attachment 74920 --> https://bugs.winehq.org/attachment.cgi?id=74920 patch for IsOS This program was tried out by someone on the forum. In default windows 10 mode it pops up a messagbox "OS not supported" and exits. The attached patch is enough to fix 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.

1 1

[Bug 55352] New: NtTerminateThread should accept handle==0 as current thread
by WineHQ Bugzilla 29 Jul '23

29 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55352 Bug ID: 55352 Summary: NtTerminateThread should accept handle==0 as current thread Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: ake.rehnman(a)gmail.com Distribution: --- Created attachment 74936 --> https://bugs.winehq.org/attachment.cgi?id=74936 Example using thread handle 0 to NtTerminateThread Windows accepts thread handle 0 as current thread. See attached example Output from example: c:\temp>test_ntterminatethread.exe h=0000000000000020 call NtTerminateThread h=0 thread exitcode=1234 -- 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 55359] New: SCICompanion crashes when trying to compile
by WineHQ Bugzilla 29 Jul '23

29 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55359 Bug ID: 55359 Summary: SCICompanion crashes when trying to compile Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: menotu3169(a)hotmail.com Distribution: --- Created attachment 74940 --> https://bugs.winehq.org/attachment.cgi?id=74940 debugging log Using SCICompanion ver3.0.1.7 (http://scicompanion.com/Downloads/SCICompanion.zip) the program freezes when trying to compile. Have only tried it with SCI0 and not SCI1. Doesn't seem to matter if I try to 'compile all' or just compile a single script. Program worked fine when tested on Windows 10. Program will pop-up with a message box saying 'Compiling scripts' but progress bar doesn't progress and entire program freezes. When frozen, I cannot click on anything or do anything and have to kill the program. Program provides a template game which can be used to replicate the issue. FILE->CREATE NEW GAME-> TEMPLATE: SCI0 then SCRIPT-> COMPILE or COMPILE ALL Linux Mint 19 - 4.15.0-213-generic AMD A6-4400M APU with Radeon(tm) HD Graphics -- 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 0

[Bug 55348] New: Hang when running executables built with AddressSanitizer
by WineHQ Bugzilla 28 Jul '23

28 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55348 Bug ID: 55348 Summary: Hang when running executables built with AddressSanitizer Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: yshuiv7(a)gmail.com Distribution: --- C code: int main(int argc, char * const* argv){ return 0; } Step to reproduce: 1. Build C code with MSVC: `cl /fsanitize=address /Zi a.c`. 2. Run the resulting executable. Result when running from wine: 0110:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 004B3CC4, 34) stub 0110:err:sync:RtlpWaitForCriticalSection section 00F8C0E0 "?" wait timed out in thread 0110, blocked by 0000, retrying (60 sec) 0110:err:sync:RtlpWaitForCriticalSection section 00F8C0E0 "?" wait timed out in thread 0110, blocked by 0000, retrying (60 sec) ... -- 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 5

[Bug 55345] New: WRC 4 changing audio volume level has no effect
by WineHQ Bugzilla 28 Jul '23

28 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55345 Bug ID: 55345 Summary: WRC 4 changing audio volume level has no effect Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: NEW Severity: minor Priority: P2 Component: xactengine Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- 08f8:fixme:xaudio2:IXACT3CueImpl_SetOutputVoiceMatrix (48AA3F18)->(052BA034 1 2 4AC3D778): stub! And also there is missing one more parameter. 8.13-43-gb5e19a33c93 -- 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