wine-bugs August 2023

wine-bugs@winehq.org

1 participants
2670 discussions

[Bug 55451] New: Application gets WM_IME_COMPOSITION without getting WM_IME_STARTCOMPOSITION before
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55451 Bug ID: 55451 Summary: Application gets WM_IME_COMPOSITION without getting WM_IME_STARTCOMPOSITION before 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: hagb(a)hagb.name Distribution: --- Created attachment 75009 --> https://bugs.winehq.org/attachment.cgi?id=75009 This program can reproduce the problem On wine 8.8 there isn't such a problem. On wine >=8.9 <=8.13, when the user uses input method to input something, the program gets some WM_IME_SETCONTEXT (0x281) messages first, and then gets WM_IME_NOTIFY (0x282, with IMN_WINE_SET_COMP_STRING 0x10), and then gets WM_IME_COMPOSITION (0x10f). There isn't a WM_IME_STARTCOMPOSITION (0x10d) sent before WM_IME_COMPOSITION. And after WM_IME_COMPOSITION, there isn't WM_IME_ENDCOMPOSITION (0x10e) either. -- 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 55465] New: user32:msg - The 64-bit test_swp_paint_region_on_show() sometimes gets a COMPLEXREGION on Windows 7
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55465 Bug ID: 55465 Summary: user32:msg - The 64-bit test_swp_paint_region_on_show() sometimes gets a COMPLEXREGION on Windows 7 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:msg - The 64-bit test_swp_paint_region_on_show() sometimes gets a COMPLEXREGION on Windows 7: msg.c:9471: Test failed: GetRgnBox (on parent) returned 3 5 rects: (10,10)-(100,33) (10,33)-(59,34) (10,34)-(57,35) (10,35)-(56,37) (10,37)-(55,100) msg.c:9508: Test failed: GetRgnBox (on parent) returned 3 5 rects: (20,20)-(120,33) (20,33)-(59,34) (20,34)-(57,35) (20,35)-(56,37) (20,37)-(55,120) msg.c:9565: Test failed: GetRgnBox (on parent) returned 3 5 rects: (10,10)-(100,33) (10,33)-(59,34) (10,34)-(57,35) (10,35)-(56,37) (10,37)-(55,100) See https://test.winehq.org/data/patterns.html#user32:msg Where 3 == COMPLEXREGION This is similar to bug 55374 except: * This only happens in 64-bit tests instead of happening exclusively in 32-bit tests. * So this also only happens on w7pro64 instead of w7u. * test_swp_paint_region_on_show() gets a COMPLEXREGION instead of a NULLREGION. So it's not immediately clear to me if both failure types have the same root cause. The oldest known instance happened on 2023-06-12 and this has happened about once a month since: * 2023-06-12 win7_newtb-w7pro64-64 * 2023-07-14 win7_newtb-w7pro64-64 * 2023-08-17 win7_newtb-w7pro64-64 -- 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 55464] New: user32:msg - test_EndDialog() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55464 Bug ID: 55464 Summary: user32:msg - test_EndDialog() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:msg - test_EndDialog() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8: msg.c:15510: Test failed: EndDialog2: 9: the msg 0x0009 was expected, but got msg 0x0047 instead msg.c:15510: Test failed: EndDialog2: 10: the msg 0x0008 was expected, but got msg 0x0009 instead msg.c:15510: Test failed: EndDialog2: 11: the msg 0x8005 was expected, but got msg 0x0008 instead msg.c:15510: Test failed: EndDialog2: 12: the msg 0x0007 was expected, but got msg 0x8005 instead msg.c:15510: Test failed: EndDialog2: 13: the msg sequence is not complete: expected 0000 - actual 0007 msg.c:15510: Failed sequence EndDialog2: msg.c:15510: 0: expected: winevent 800a - actual: WEH: winevent 00E001DA 0000800a 00000000 00000000 msg.c:15510: 1: expected: msg 000a - actual: parent: 00E001DA 000a wp 00000001 lp 00000000 (flags 1d) msg.c:15510: 2: expected: msg 0046 - actual: dialog: 002C01EA WM_WINDOWPOSCHANGING wp 00000000 lp 00ccf870 after 00000000 x 0 y 0 cx 0 cy 0 flags SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOZORDER|SWP_NOSIZE|SWP_NOMOVE (flags 19) msg.c:15510: 3: expected: hook 0005 - actual: CBT: hook 5 (HCBT_ACTIVATE) wp 00e001da lp 00ccf89c msg.c:15510: 4: expected: msg 0086 - actual: dialog: 002C01EA 0086 wp 00000000 lp 00e001da (flags 19) msg.c:15510: 5: expected: msg 0006 - actual: dialog: 002C01EA 0006 wp 00000000 lp 00e001da (flags 19) msg.c:15510: 6: expected: winevent 0003 - actual: WEH: winevent 00E001DA 00000003 00000000 00000000 msg.c:15510: 7: expected: msg 0046 - actual: dialog: 002C01EA WM_WINDOWPOSCHANGING wp 00000000 lp 00ccf888 after 0001008A x 0 y 0 cx 0 cy 0 flags SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE (flags 19) msg.c:15510: 8: expected: msg 0046 - actual: dialog: 002C01EA WM_WINDOWPOSCHANGED wp 00000000 lp 00ccf888 after 0001008A x 108 y 131 cx 156 cy 192 flags SWP_NOACTIVATE|SWP_NOREDRAW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE (flags 19) msg.c:15510: 9: expected: hook 0009 - actual: dialog: 002C01EA WM_WINDOWPOSCHANGED wp 00000000 lp 00ccf888 after 0001008A x 108 y 131 cx 156 cy 192 flags SWP_NOACTIVATE|SWP_NOREDRAW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE (flags 19) msg.c:15510: 10: expected: msg 0008 - actual: CBT: hook 9 (HCBT_SETFOCUS) wp 00e001da lp 002c01ea msg.c:15510: 11: expected: winevent 8005 - actual: dialog: 002C01EA 0008 wp 00e001da lp 00000000 (flags 19) msg.c:15510: 12: expected: msg 0007 - actual: WEH: winevent 00E001DA 00008005 fffffffc 00000000 msg.c:15510: 13: expected: nothing - actual: parent: 00E001DA 0007 wp 002c01ea lp 00000000 (flags 3d) See https://test.winehq.org/data/patterns.html#user32:msg This only happened twice so far and both times on Windows 8: * 2023-08-08 win81_newtb-w8 * 2023-08-18 win81_newtb-w8adm -- 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 55463] New: user32:msg - test_SetFocus() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55463 Bug ID: 55463 Summary: user32:msg - test_SetFocus() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:msg - test_SetFocus() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows: msg.c:18822: Test failed: SetFocus on a child window: 5: the msg 0x001c was expected, but got msg 0x0047 instead msg.c:18822: Failed sequence SetFocus on a child window: msg.c:18822: 0: expected: hook 0009 - actual: CBT: hook 9 (HCBT_SETFOCUS) wp 008f00e0 lp 00000000 msg.c:18822: 1: expected: hook 0005 - actual: CBT: hook 5 (HCBT_ACTIVATE) wp 008d00c4 lp 0034f5f8 msg.c:18822: 2: expected: winevent 0003 - actual: WEH: winevent 00000000008D00C4 00000003 00000000 00000000 msg.c:18822: 3: expected: msg 030f - actual: parent: 00000000008D00C4 WM_WINDOWPOSCHANGING wp 00000000 lp 0034f5e0 after 0000000000C600FA x 0 y 0 cx 0 cy 0 flags SWP_NOSIZE|SWP_NOMOVE (flags 1d) msg.c:18822: 4: expected: msg 0046 - actual: parent: 00000000008D00C4 WM_WINDOWPOSCHANGING wp 00000000 lp 0034f5e0 after 0000000000C600FA x 0 y 0 cx 0 cy 0 flags SWP_NOSIZE|SWP_NOMOVE (flags 1d) msg.c:18822: 5: expected: msg 001c - actual: parent: 00000000008D00C4 WM_WINDOWPOSCHANGED wp 00000000 lp 0034f5e0 after 0000000000C600FA x 0 y 0 cx 132 cy 38 flags SWP_NOREDRAW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE (flags 1d) msg.c:18822: 6: expected: msg 0086 - actual: parent: 00000000008D00C4 000d wp 00000208 lp 0034e6f0 (flags 1d) msg.c:18822: 7: expected: msg 000d - actual: parent: 00000000008D00C4 WM_NCCALCSIZE: winpos->cx 132, winpos->cy 38 (flags 1d) msg.c:18822: 8: expected: msg 000d - actual: parent: 00000000008D00C4 WM_NCCALCSIZE: winpos->cx 132, winpos->cy 38 (flags 1d) msg.c:18822: 9: expected: msg 0006 - actual: parent: 00000000008D00C4 WM_NCCALCSIZE: winpos->cx 132, winpos->cy 38 (flags 1d) msg.c:18822: 10: expected: hook 0009 - actual: WEH: winevent 00000000008D00C4 0000800b 00000000 00000000 msg.c:18822: 11: expected: winevent 8005 - actual: parent: 00000000008D00C4 001c wp 00000001 lp 00000220 (flags 1d) msg.c:18822: 12: expected: msg 0007 - actual: parent: 00000000008D00C4 0086 wp 00000001 lp 00000000 (flags 1d) msg.c:18822: 13: expected: msg 0008 - actual: parent: 00000000008D00C4 000d wp 00000208 lp 0034e330 (flags 3d) msg.c:18822: 14: expected: winevent 8005 - actual: parent: 00000000008D00C4 000d wp 00000208 lp 0034e380 (flags 3d) msg.c:18822: 15: expected: msg 0007 - actual: parent: 00000000008D00C4 0006 wp 00000001 lp 00000000 (flags 1d) msg.c:18822: 16: expected: nothing - actual: CBT: hook 9 (HCBT_SETFOCUS) wp 008d00c4 lp 00000000 msg.c:18822: 17: expected: nothing - actual: WEH: winevent 00000000008D00C4 00008005 fffffffffffffffc 00000000 msg.c:18822: 18: expected: nothing - actual: parent: 00000000008D00C4 0007 wp 00000000 lp 00000000 (flags 3d) msg.c:18822: 19: expected: nothing - actual: parent: 00000000008D00C4 0008 wp 008f00e0 lp 00000000 (flags 1d) msg.c:18822: 20: expected: nothing - actual: WEH: winevent 00000000008F00E0 00008005 fffffffffffffffc 00000000 msg.c:18822: 21: expected: nothing - actual: MsgCheckProc: 00000000008F00E0 0007 wp 008d00c4 lp 00000000 (flags 19) See https://test.winehq.org/data/patterns.html#user32:msg Where 0x001c == WM_ACTIVATEAPP 0x0047 == WM_WINDOWPOSCHANGED The first known instance happened on 2023-06-12 and this has happened about once every other week since: * 2023-06-12 win7_newtb-w7u-pt-PT * 2023-06-14 win21H1_newtb-w10pro64-zh-CN-64 * 2023-07-06 win7_newtb-w7pro64-64 * 2023-07-13 win7_newtb-w7pro64-64_1 * 2023-08-10 win7_newtb-w7pro64-64 -- 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 55462] New: mfplay:mfplay sometimes times out on Windows 7
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55462 Bug ID: 55462 Summary: mfplay:mfplay sometimes times out on Windows 7 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com mfplay:mfplay sometimes times out on Windows 7: mfplay:mfplay:0a24 done (258) in 120s 0B See https://test.winehq.org/data/patterns.html#mfplay:mfplay The test normally runs in under 1 second which means the time out is caused by a deadlock. However this is pretty rare and has only happened in 1.6% of the WineTest runs and only on Windows 7: * 2023-02-22 win7_newtb-w7pro64-64 * 2023-03-02 win7_newtb-w7pro64-64 * 2023-05-10 win7_newtb-w7u-adm * 2023-07-13 win7_newtb-w7pro64-64_1 * 2023-08-17 win7_newtb-w7pro64-64 -- 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 52569] New: Zothero Error Launch XUL
by WineHQ Bugzilla 19 Aug '23

19 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=52569 Bug ID: 52569 Summary: Zothero Error Launch XUL Product: Wine Version: 7.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: blbenyamin9(a)gmail.com Distribution: --- Created attachment 71889 --> https://bugs.winehq.org/attachment.cgi?id=71889 Zothero Error Launch Zothero, and imidietly got this error Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x0258904c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:0258904c ESP:0051cb84 EBP:0051dcec EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:00000000 ECX:0051cb44 EDX:00990094 ESI:009d13e8 EDI:0bc9d478 -- 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

[Bug 55344] New: Yuzu fails to start (needs MSVCP140_CODECVT_IDS.dll)
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55344 Bug ID: 55344 Summary: Yuzu fails to start (needs MSVCP140_CODECVT_IDS.dll) Product: Wine Version: 8.12 Hardware: x86-64 URL: https://web.archive.org/web/20230727051938/https://git hub.com/yuzu-emu/yuzu-mainline/releases/download/mainl ine-0-1503/yuzu-windows-msvc-20230722-3dfaf1ff2.tar.xz OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: lingm+winebz(a)posteo.org Distribution: --- 1. Download and extract the Windows version of Yuzu 1503. https://github.com/yuzu-emu/yuzu-mainline/releases/tag/mainline-0-1503 (see the URL field for a direct archived link) 2. Run `wine yuzu.exe` 3. No window even shows up. The full output is: ``` $ wine yuzu.exe 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 00d8:err:module:import_dll Library MSVCP140_CODECVT_IDS.dll (which is needed by L"$snip_path$\\yuzu.exe") not found 00d8:err:module:LdrInitializeThunk Importing dlls for L"$snip_path$\\yuzu.exe" failed, status c0000135 ``` `winetricks vcrun2019` works around this problem and allows Yuzu to start properly. -- 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 55331] New: ntdll:file - The 64-bit test_file_disposition_information() gets unsupported error on Windows 10 1607 and 1709
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55331 Bug ID: 55331 Summary: ntdll:file - The 64-bit test_file_disposition_information() gets unsupported error on Windows 10 1607 and 1709 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 - The 64-bit test_file_disposition_information() gets unsupported error on Windows 10 1607 and 1709: file.c:3141: Test failed: unexpected FileDispositionInformationEx result (expected STATUS_SUCCESS or SSTATUS_INVALID_INFO_CLASS, got c00000bb) See https://test.winehq.org/data/patterns.html#ntdll:file Where c00000bb == STATUS_NOT_SUPPORTED c0000003 == STATUS_INVALID_INFO_CLASS This is a case where early Windows 10 versions don't fully support FileDispositionInformationEx(). Further tests show that: * On Windows 10 1507 we get STATUS_INVALID_INFO_CLASS as expected by the test. * On Windows 10 1607 the 32-bit case gets STATUS_INVALID_INFO_CLASS too but the 64-bit one gets STATUS_NOT_SUPPORTED. * On Windows 10 1709 gets STATUS_NOT_SUPPORTED in both 32 and 64-bit. * And Windows 10 1809 gets STATUS_SUCCESS in both cases. The failures started on 2023-06-27 and a quick test confirms they are caused by the commit that added the test: commit cbc1e4423e6d40221734544d081c718cb2a2a778 Author: Joel Holdsworth <joel(a)airwebreathe.org.uk> AuthorDate: Mon May 1 15:27:57 2023 +0100 ntdll/tests: Add tests for FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE. Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk> -- 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 3

[Bug 54676] New: winetricks --verify dotnet20 (AutoHotKey) fails in a wow64 build
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54676 Bug ID: 54676 Summary: winetricks --verify dotnet20 (AutoHotKey) fails in a wow64 build Product: Wine Version: 8.3 Hardware: x86-64 OS: Linux Status: NEW Keywords: dotnet, download, wow64 Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Debian Created attachment 74190 --> https://bugs.winehq.org/attachment.cgi?id=74190 terminal output The install itself seems to go okay (at least, it exits successfully in quiet mode). Running --verify (which should run the .Net verifier tool) instead just hangs on: /opt/oldwownew/wine-8.3/bin/wine y:\ahk\AutoHotkeyU32.exe C:\windows\Temp\dotnet20.ahk -- 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 3

[Bug 55127] New: httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on Windows 10
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55127 Bug ID: 55127 Summary: httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on Windows 10 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on Windows 10: httpapi.c:1426: Test failed: Connecting to socket succeeded, 0. httpapi.c:1427: Test failed: Unexpected error connecting to socket, 0. See https://test.winehq.org/data/patterns.html#httpapi:httpapi This failure first happened on 2023-02-09 and has happened 4 times since then: * 2023-02-09 win22H2_fgtb-w10pro64-32 * 2023-03-30 win22H2_fgtb-w10pro64-32 * 2023-05-30 win2009_newtb-w1064v2009-64 * 2023-06-15 win2009_newtb-w1064v2009-64 -- 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 3

[Bug 54866] New: ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an unexpected session count on Windows
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54866 Bug ID: 54866 Summary: ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an unexpected session count on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ieframe Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an unexpected session count on Windows: webbrowser.c:4440: init_count 1 webbrowser.c:4443: Test failed: count = 3 webbrowser.c:4446: Test failed: count = 3 webbrowser.c:4449: Test failed: count = 2 webbrowser.c:4452: Test failed: count = 2 See https://test.winehq.org/data/patterns.html#ieframe:webbrowser These failures only happen on Windows 10 21H1 to 22H2. On Windows 10 init_count is either 1 or 2 (on w8adm is can be 0 too), but all the failures so far happened with an init_count of 1. That said there are also a lot of successful runs with init_count == 1. This looks a lot like the browser creates a net session for its own purposes: * Either init_count is 1 and the extra net session is never created or gets created after test_SetQueryNetSessionCount() is done so all is fine. * Or the extra net session is created it before test_SetQueryNetSessionCount() starts and outlives it so our tests pass. * Or the extra net session gets created after we get init_count but before the next test so that all our tests are off by one. * But it seems the extra net session never gets created after the first SESSION_INCREMENT test. Note that on my Windows 10 VM when I start iexplorer.exe by hand and then run the test I always get init_count == 2. But if IE is not already running I get init_count == 0. In any case if it's a race condition I could send a patch to retry a couple of times. -- 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 3

[Bug 54073] New: ws2_32:sock - test_close_events() sometimes fails in Wine
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54073 Bug ID: 54073 Summary: ws2_32:sock - test_close_events() sometimes fails in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ws2_32:sock - test_close_events() sometimes fails in Wine: sock.c:6775: Test succeeded inside todo block: event series matches sock.c:6785: Test failed: got unexpected event 0x20 sock.c:6785: Test failed: event series matches See https://test.winehq.org/data/patterns.html#ws2_32:sock This happens in the nightly WineTest runs about twice per month but also impacts merge requests (for instance MR!1524 and MR!1525 where it happened on the GitLab CI). -- 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 48621] New: Civilization 6 crashes on startup.
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=48621 Bug ID: 48621 Summary: Civilization 6 crashes on startup. Product: Wine Version: 5.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: charles2000wang(a)gmail.com Distribution: --- Created attachment 66468 --> https://bugs.winehq.org/attachment.cgi?id=66468 Game Log file Launching the game opens a black window before promptly crashes with the Firaxis Crash Reporter asking to submit a report. Digging around the game files, I found a log file (GameOverlayRenderer.log) with messages about "Aborting HookFunc because pRealFunctionAddr is null" and other errors. -- 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 36564] New: 'Candytron' demo: certain objects are black with GLSL enabled
by wine-bugs＠winehq.org 18 Aug '23

18 Aug '23

http://bugs.winehq.org/show_bug.cgi?id=36564 Bug ID: 36564 Summary: 'Candytron' demo: certain objects are black with GLSL enabled Product: Wine Version: 1.6-rc1 Hardware: x86 URL: http://www.pouet.net/prod.php?which=9424 OS: Linux Status: NEW Keywords: download, regression Severity: trivial Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: hverbeet(a)gmail.com Regression SHA1: 2014141a253a791fc9c79aae3c8ef3c35b73e658 Created attachment 48657 --> http://bugs.winehq.org/attachment.cgi?id=48657 screenshot (comparison) Some of the rectangles that appear in the demo nearly at 00:30 and at 01:10 are black. They should appear as glowing green rectangles as can be seen in the attached screenshot. Terminal output doesn't reveal anything interesting. Disabling GLSL is a workaround. This is a regression from Wine 1.6-rc1: 2014141a253a791fc9c79aae3c8ef3c35b73e658 is the first bad commit commit 2014141a253a791fc9c79aae3c8ef3c35b73e658 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed May 29 09:45:35 2013 +0200 wined3d: Add support for GLSL based fixed function vertex shaders. :040000 040000 d1b4b75f643d4851d4f51454aa47740261f7857f c46794f61b1952b1e78746272d838574c0948010 M dlls Fedora 20 Nvidia 250 gfx card / Nvidia binary drivers 337.19 wine-1.7.19-70-gd6a59f7 -- 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 20

[Bug 55367] New: Trying to run WatchFaceStudio with wine 8.0 and Ubuntu 23 (lunar)
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55367 Bug ID: 55367 Summary: Trying to run WatchFaceStudio with wine 8.0 and Ubuntu 23 (lunar) Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tda.bkp(a)gmail.com Distribution: --- Created attachment 74949 --> https://bugs.winehq.org/attachment.cgi?id=74949 WatchFaceStudio.exe crash trace Installed WatchFaceStudio successfully, but won't run. Trace 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 2

[Bug 54831] New: GStreamer gst_init_check() crashes when called from winegstreamer on recent macOS
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54831 Bug ID: 54831 Summary: GStreamer gst_init_check() crashes when called from winegstreamer on recent macOS Product: Wine Version: 8.5 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)winehq.org Reporter: bshanks(a)codeweavers.com On macOS Ventura (and I suspect Monterey), gst_init_check() crashes (trying to jump to 0x0) when called by winegstreamer. This is caused by the macOS preloader, here's how: * gst_init_check() calls init_static_plugins() <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.22/subprojects/…>, which through some GModule abstractions does a dlopen(NULL) and dlsym() for a symbol that doesn't exist. dlsym() returns NULL, but GModule also calls dlerror() which returns NULL (signaling no error). * init_static_plugins() therefore thinks that the dlsym() was successful, doesn't do a NULL pointer check, and jumps to the NULL pointer. The issue here is dlerror() returning NULL despite there being an error to report. Looking at the macOS dyld source code (<https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/dyld/DyldA…>), dlerror() always returns NULL if libSystem was not initialized in the process. And sure enough, when running vmmap on a Wine process, the message "Process exists but has not fully started -- dyld has initialized but libSystem has not" is printed. After more searching in dyld, it turns out that dyld initializes libSystem for binaries targeting 10.5 and newer. The Wine preloader targets 10.7 (since that's the newest target that will generate an LC_UNIXTHREAD binary, critical to how the preloader works). But dyld determines the target OS based on where the program vars (argc, argv, environ, etc) are stored, and a 10.6/10.7 binary should contain a __program_vars section for those. The preloader is missing that, and so (I believe) it falls down to being considered a 10.4 binary. A 10.4 binary should init libSystem in its own _start, but the preloader also doesn't do this, and libSystem stays uninitialized. (See <https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/common/Mac…> for where this is determined) I see several possible solutions: * The most obvious one: add a __program_vars section to the preloader, to make it a correct 10.7 binary. In fact, the code can basically be copied out of Apple's C startup code (<https://github.com/apple-opensource/Csu/blob/88/crt.c#L47>). This does work, and libSystem gets initialized. However, libSystem is initialized before any preloader code runs, and malloc zones are already in the middle of areas we want to reserve. That's bad; by itself this approach won't work, but it might if we also: - add linker zerofill sections to block off the entire low 4GB. This is desirable to reserve as much address space as possible for 32-bit EXEs in wow64 mode. - and if zerofill sections are also added to reserve the area where 64-bit EXEs generally load (0x14000000), it might even be possible to stop using the preloader altogether on 64-bit. * Alternately, go the other way, and lean in to being a 10.4 binary. In that case, _start in the preloader needs to call back into dyld to initialize things (like this: <https://github.com/apple-opensource/Csu/blob/88/crt.c#L219>). We could do this after reserving our areas. I'm leery of this approach, mainly because x86_64/10.4 was not a popular target (GUI apps were not supported, they could only link against libSystem). If possible, I'd rather not target such an obscure combination. The preloader has been a source of problems with new OS versions, and I'd like to decrease the amount of black magic it's doing, not increase it. (Running 10.4 x86_64 binaries on modern macOS is still supported though, and Xcode can even still build them.) I'd like to make the __program_vars+zerofill approach work if possible. -- 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 54748] New: Greenshot GDI+ status: PropertyNotFound
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54748 Bug ID: 54748 Summary: Greenshot GDI+ status: PropertyNotFound Product: Wine Version: 8.3 Hardware: x86-64 URL: https://objects.githubusercontent.com/github-productio n-release-asset-2e65be/36756917/23e6800e-7d29-11e7-8ac 5-aa92e5646973?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz- Credential=AKIAIWNJYAX4CSVEH53A%2F20230328%2Fus-east-1 %2Fs3%2Faws4_request&X-Amz-Date=20230328T165105Z&X-Amz -Expires=300&X-Amz-Signature=311e88c8da4b8ba0ff5ac6008 cf054338cd6e18afcf64471443530ddae088db0&X-Amz-SignedHe aders=host&actor_id=0&key_id=0&repo_id=36756917&respon se-content-disposition=attachment%3B%20filename%3DGree nshot-NO-INSTALLER-1.2.10.6-RELEASE.zip&response-conte nt-type=application%2Foctet-stream OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: lukasz.wojnilowicz(a)gmail.com Distribution: --- Steps to reproduce: 1) unpack Greenshot-NO-INSTALLER-1.2.10.6-RELEASE.zip 2) wine Greenshot.exe 3) RMB on Greenshot icon in the system tray 4) LMB on "Capture region" 5) Draw a rectangel on your screen Behavior: Error window with contents as below. Expected behavior: No error window. Error window contents: Software version: 1.2.10.6-RELEASE-c2414cf0149a1475ea00520effc01b40087c225c (32 bit) .NET runtime version: 4.0.30319.42000+ Time: 2023-03-28 18:59:01 +02:00 OS: unknown (x32) 10.0 build 2600 revision 30000 GDI object count: 0 User object count: 0 Exception: System.Exception Message: Unknown Error [GDI+ status: PropertyNotFound] Stack: at System.Drawing.GDIPlus.CheckStatus (System.Drawing.Status status) [0x0022b] in <fc2ea6474c6d4315858618f13de6e72a>:0 at System.Drawing.Image.get_PropertyItems () [0x00017] in <fc2ea6474c6d4315858618f13de6e72a>:0 at (wrapper remoting-invoke-with-check) System.Drawing.Image.get_PropertyItems() at GreenshotPlugin.Core.ImageHelper.CloneArea (System.Drawing.Image sourceImage, System.Drawing.Rectangle sourceRect, System.Drawing.Imaging.PixelFormat targetFormat) [0x00172] in <68959698d73243a09b84293d02c00b84>:0 at GreenshotPlugin.Core.ImageHelper.Crop (System.Drawing.Image& image, System.Drawing.Rectangle& cropRectangle) [0x00046] in <68959698d73243a09b84293d02c00b84>:0 at GreenshotPlugin.Core.Capture.Crop (System.Drawing.Rectangle cropRectangle) [0x0001a] in <68959698d73243a09b84293d02c00b84>:0 at Greenshot.Helpers.CaptureHelper.CaptureWithFeedback () [0x00085] in <64ca337812514938b5bb8fc98fce780b>:0 at Greenshot.Helpers.CaptureHelper.MakeCapture () [0x008a0] in <64ca337812514938b5bb8fc98fce780b>:0 at Greenshot.Helpers.CaptureHelper.CaptureRegion (System.Boolean captureMouse) [0x00008] in <64ca337812514938b5bb8fc98fce780b>:0 at Greenshot.MainForm+<>c.<CaptureAreaToolStripMenuItemClick>b__52_0 () [0x00000] in <64ca337812514938b5bb8fc98fce780b>:0 at System.Windows.Forms.Control.InvokeMarshaledCallbackDo (System.Windows.Forms.Control+ThreadMethodEntry tme) [0x000c0] in <d22f8be2dd674c49bd49b314423240b8>:0 at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper (System.Object obj) [0x00029] in <d22f8be2dd674c49bd49b314423240b8>:0 at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00071] in <e70d6e9587d64cb3abb4b3f99bbf5a0d>:0 at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <e70d6e9587d64cb3abb4b3f99bbf5a0d>:0 at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x0002b] in <e70d6e9587d64cb3abb4b3f99bbf5a0d>:0 at System.Windows.Forms.Control.InvokeMarshaledCallback (System.Windows.Forms.Control+ThreadMethodEntry tme) [0x0004d] in <d22f8be2dd674c49bd49b314423240b8>:0 at System.Windows.Forms.Control.InvokeMarshaledCallbacks () [0x0008a] in <d22f8be2dd674c49bd49b314423240b8>:0 Terminal output: 0024:fixme:dwmapi:DwmGetWindowAttribute (0003008E 9 0021DA80 16) stub 0024:fixme:uiautomation:UiaClientsAreListening () 0024:fixme:dwmapi:DwmGetWindowAttribute (00050086 9 0021D620 16) stub 0024:fixme:dwmapi:DwmGetWindowAttribute (00050070 9 0021C850 16) stub Additional info: seems to happen on NET 4.5 and Mono as well -- 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 54546] New: ws2_32:sock - test_write_watch() gets unexpected write counts on Windows 11
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=54546 Bug ID: 54546 Summary: ws2_32:sock - test_write_watch() gets unexpected write counts on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com ws2_32:sock - test_write_watch() gets unexpected write counts on Windows 11: sock.c:7670: Test failed: wrong count 0 sock.c:7701: Test failed: wrong count 0 sock.c:7735: Test failed: wrong count 0 sock.c:7735: Test failed: wrong count 0 sock.c:7735: Test failed: wrong count 0 sock.c:7735: Test failed: wrong count 0 See https://test.winehq.org/data/patterns.html#ws2_32:sock -- 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 3

[Bug 52889] New: Freelancer with Crossfire mod crashes on startup
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=52889 Bug ID: 52889 Summary: Freelancer with Crossfire mod crashes on startup Product: Wine Version: 6.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: poweroverwhelming982(a)gmail.com CC: jacek(a)codeweavers.com Regression SHA1: 6857cb56957d691bee76cfe28ef88714cca00f29 Distribution: Ubuntu Created attachment 72282 --> https://bugs.winehq.org/attachment.cgi?id=72282 Wine log at commit 6857cb56957d691bee76cfe28ef88714cca00f29 Since wine-6.19, Freelancer with Crossfire 2.0 mod crashes immediately on startup (as soon as the mod window is shown). Bisecting points to this commit: > commit 6857cb56957d691bee76cfe28ef88714cca00f29 > Author: Jacek Caban <jacek(a)codeweavers.com> > Date: Wed Sep 29 14:09:21 2021 +0200 > > gdi32: Move ntgdi functions to Unix library. I've attached the relevant logs, let me know if there's anything else I can do. Additional info: OS: Ubuntu Focal 20.04.3 LTS Kernel: 5.13.0-30-generic x86_64 Wine Prefix: 32 bit, clean GPU: NVIDIA Corporation GF108 [GeForce GT 730] (rev a1) Graphics Driver: Proprietary NVIDIA ver. 390.144 -- 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 52474] New: ws2_32:sock fails intermittently - 'Test failed: expected timeout'
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=52474 Bug ID: 52474 Summary: ws2_32:sock fails intermittently - 'Test failed: expected timeout' Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: jinoh.kang.kr(a)gmail.com Distribution: --- The test_connect_events() function contains the following checks, where the check (2) fails intermittently: 1. check_events(ctx, FD_CONNECT, FD_WRITE, 200); 2. check_events(ctx, 0, 0, 0); A hypothesis for the cause of the test failure is that the WSAEnumNetworkEvents() call inside the check (1) races with the server setting the event. Note that WSAEnumNetworkEvents performs the following steps: a. It calls ResetEvent on the given event. b. It issues IOCTL_AFD_GET_EVENTS command on the socket to retrieve the events so far. It's possible that the event may be set by the server between (a) and (b), which lingers until the next call to WSAEnumNetworkEvents(). This explains why the event wait in check (2) is satisfied immediately but subsequent tests report no events. -- 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 34678] New: Not all serial port work in wine
by wine-bugs＠winehq.org 18 Aug '23

18 Aug '23

http://bugs.winehq.org/show_bug.cgi?id=34678 Bug #: 34678 Summary: Not all serial port work in wine Product: Wine Version: 1.6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: rewineland(a)gmail.com Classification: Unclassified I have wine 1.6 install on Ubuntu 12.04 with kernel 3.8.0-31-generial. I have 2 serial ports on board and an add-on card with 8 more.I can get the the on board and 7 of the add-on to work as 1 though 9 comports but com10 I can not get any data though. the port is listed as ttyCTI7, when I connect to that I have data going back and forth. It just wont go into the windows program. Any ideas on what to do. I need to have all 10 ports. -- 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 10

[Bug 55283] New: amstream:amstream systematically crashes and times out on gitlab-debian-32
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55283 Bug ID: 55283 Summary: amstream:amstream systematically crashes and times out on gitlab-debian-32 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: major Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- amstream:amstream systematically crashes and times out on gitlab-debian-32: Unhandled exception: assertion failed in wow64 32-bit code (0xf7f19559). Backtrace: =>0 0xf7f9a559 __kernel_vsyscall+0x9() in [vdso].so (0xf7f34ff4) 1 0xf7da21d7 in libc.so.6 (+0x8a1d7) (0xf7f34ff4) 2 0xf7d510d1 in libc.so.6 (+0x390d1) (0xf7f34ff4) 3 0xf7d3a26a in libc.so.6 (+0x2226a) (0xf7f34ff4) 4 0x71a4de79 in libllvm-15.so.1 (+0x875e79) (0x0022e910) 5 0x00000040 (0x00000040) 0xf7f9a559 __kernel_vsyscall+0x9 in [vdso].so: pop %ebp See https://test.winehq.org/data/patterns.html#amstream:amstream The failures started on 2023-07-10 which corresponds to the GitLab CI switch to Debian 12. What makes this very bad is that the failure is systematic so every single merge request has been getting a GitLab CI error since then. So it is pretty urgent to either: 1. Fix the test if something is wrong with it. 2. Fix the gitlab-debian-32 test environment if it is wrong. 3. Skip amstream:amstream if neither of the above is doable in a reasonable timeframe. -- 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 15

[Bug 53171] New: advapi32:registry - test_performance_keys() sometimes fails due to time going backwards!
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=53171 Bug ID: 53171 Summary: advapi32:registry - test_performance_keys() sometimes fails due to time going backwards! Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com advapi32:registry - test_performance_keys() sometimes fails due to time going backwards: registry.c:3757: Test failed: key FFFFFFFF80000004: value (null): got times 132999520626290092, 132999520626290092, 132967560392269933 registry.c:3763: Test failed: key FFFFFFFF80000004: value (null): got times 132999520626290092, 132999520626290000, 132967560392269933 https://test.winehq.org/data/patterns.html#advapi32:registry This failure is pretty rate: I only found 4 cases (~0.9%): win2009_newtb-w1064-tsign, win21H1_newtb-w10pro64-mx-MX, 2x win21H2_fgtb-w10pro64. The failure lines above happened on w10pro64-mx-MX on 2022-06-17. Here are the corresponding timestamps: systime1 = 132999520626290092 = 2022-06-17 15:07:42.629009 file_time = 132999520626290000 = 2022-06-17 15:07:42.629000 systime2 = 132967560392269933 = 2022-05-11 15:20:39.226993 file_time is a little lower than systime1 which is normal due to its granularity. What is totally wrong however is that systime2 is way lower than systime1. The interesting part is that the live snapshot was created on 2022-05-11 which matches systime2. This scenario is confirmed it two of the other instances; the snapshot creation time for the last case is unknown but a match with systime2 is plausible. After restoring the VM from the live snapshot LibvirtTool sets the VM time through TestAgent::SetTime(): https://gitlab.winehq.org/winehq/tools/-/blob/master/testbot/bin/LibvirtToo… https://gitlab.winehq.org/winehq/tools/-/blob/master/testbot/src/testagentd… So it looks like in rare cases the system time gets reset backwards precisely between this test's two NtQuerySystemTime() calls, which is really unlucky... or lucky: maybe it happens in other cases causing less obvious failures. I don't know if TestAgentd sets the time wrong, if there's something wrong with Windows, or if this is an artifact of the QEmu clocks: <clock offset='localtime'> <timer name='rtc' tickpolicy='delay'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='yes'/> <timer name='hypervclock' present='yes'/> </clock> -- 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 52492] New: stack overflow from GdipFlattenPath
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=52492 Bug ID: 52492 Summary: stack overflow from GdipFlattenPath Product: Wine Version: 7.1 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: rjfeuerbach(a)gmail.com Created attachment 71787 --> https://bugs.winehq.org/attachment.cgi?id=71787 test patch to replicate the curves and stack overflow I have a third party application, unfortunately not available for download, that is generating a virtual stack overflow error. Using +replay and eventually +gdiplus messages, the cause was narrowed down to be due to calls to GdipFlattenPath. Attached is a patch to gdiplus/test/graphicspath.c to include the precise curves that cause the stack overflow. I believe the problem is due to the comparison of REALs with == in the flatten_bezier helper function. -- 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 22

[Bug 55422] New: mfmediaengine:mfmediaengine - test_GetDuration() fails in Wine
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

https://bugs.winehq.org/show_bug.cgi?id=55422 Bug ID: 55422 Summary: mfmediaengine:mfmediaengine - test_GetDuration() fails in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- mfmediaengine:mfmediaengine - test_GetDuration() fails in Wine: mfmediaengine.c:1961: Test failed: Unexpected res 0x102. See https://test.winehq.org/data/patterns.html#mfmediaengine:mfmediaengine This failure started with the commit that introduced the tests: commit 613d7b099986828212299a8e98179f22c86b80ab Author: Zhiyi Zhang <zzhang(a)codeweavers.com> Date: Fri Aug 4 17:35:04 2023 +0800 mfmediaengine/tests: Test IMFMediaEngine::GetDuration(). -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs August 2023