August 2026 - Wine-Bugs - list.winehq.org

[Bug 58134] New: GTA San Andreas: A required security module can not be activated.
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=58134 Bug ID: 58134 Summary: GTA San Andreas: A required security module can not be activated. Product: Wine Version: unspecified Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Hello, when i want to start GTA San Andreas using the original disc copy then i do get the message "A required security module can not be activated. This program can not be executed". The game is using SecuROM. Tested with Wine 10.3 Thanks in advance. -- 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 29372] New: Chrome exit with "fixme:file:ReplaceFileW Ignoring flags 2" while dragging tabs
by wine-bugs＠winehq.org Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=29372 Bug #: 29372 Summary: Chrome exit with "fixme:file:ReplaceFileW Ignoring flags 2" while dragging tabs Product: Wine Version: 1.3.35 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified 1. Downlaod and install Google Chrome http://www.google.com/chrome/index.html?platform=win&hl=en&standalone=1 sha1sum : ChromeStandaloneSetup-b6ea56f7a04f9bcee3565687f5aef83695d13b97-2011-12-09.exe 2. disable "Allow the window manager to decorate the windows." in winecfg (Reference: Bug 28467 and Bug 28468) 3. Start chrome $ cd ~/.wine/drive_c/users/fracting/Local\ Settings/Application\ Data/Google/Chrome/Application $ wine chrome.exe 4. make sure there is only one tab, drag the chrome tab away from the origin position, then chrome will exit with following messages: fixme:file:ReplaceFileW Ignoring flags 2 fixme:file:ReplaceFileW Ignoring flags 2 fixme:file:ReplaceFileW Ignoring flags 2 fixme:iphlpapi:CancelIPChangeNotify (overlapped 0xc8ab1c): stub fixme:advapi:UnregisterTraceGuids 0: stub fixme:advapi:UnregisterTraceGuids 0: stub -- 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 14

[Bug 30652] New: Wrong TextOut font substitution under en_US locale
by wine-bugs＠winehq.org Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=30652 Bug #: 30652 Summary: Wrong TextOut font substitution under en_US locale Product: Wine Version: 1.5.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: hqm03ster(a)gmail.com Classification: Unclassified Created attachment 40125 --> http://bugs.winehq.org/attachment.cgi?id=40125 The screenshots, test code, and test font The test program "tunihan.c" behaves differently on Windows and Wine (under linux). When a Unicode string containing CJK characters is TextOut-ed using a custom font, Wine font substitution isn't working properly like Windows does. To reproduce: 1. Install the font "nkf11_magicum_texturae.ttf". The font can be downloaded for free at: http://hwm3.gyao.ne.jp/shiroi-niwatori/nkf11_magicum_texturae.zip Windows standard CJK fonts NSimSun, PMingLiu, MS UI Gothic, Tahoma are also required to completely reproduce the attached screenshots. 2. Compile attached tunihan.c using MinGW on Windows with command line: gcc -otunihan.exe tunihan.c -lgdi32 3. Run the generated tunihan.exe under Windows, with global non-Unicode program locale set to English (US). Attached screenshot "enUS-windows.png" should be reproduced. 4. Copy/link all Windows fonts into Wine. 5. Run the generated tunihan.exe under Wine using command line: LANG=en_US.utf8 wine tunihan.exe Attacehed screenshot "enUS-linux.png" should be reproduced. Test environment: Windows: A Chinese Edition of Windows 7 with global non-Unicode program locale set to English (US). Wine: Wine 1.5.4 on Arch Linux 3.3.5, with all windows fonts symlinked into "C:\windows\Fonts" in Wine. Notes: A. The attached font, "nkf11_magicum_texturae.ttf", is an incomplete fictional glyph set for ASCII characters. It is chosen as a test font because it is missing glyphs for a number of ASCII symbols (e.g. '[', ']'), is clearly distinguishable from any potential substitution font, and is clearly not a Windows standard font. B. This behavior can't be reproduced using AppLocale. The Windows machine must have its global non-Unicode program locale set to English (US). C. tunihan.c writes 7 lines of texts to a Window: Line 1: A line of ASCII/CJK characters in a Simplified Chinese font Line 2: A line of ASCII/CJK characters in a Traditional Chinese font Line 3: A line of ASCII/CJK characters in a Japanese font Line 4: A line of ASCII/CJK characters in the test font Line 5: A line of ASCII characters in the test font, using TextOutW Line 6: A line of ASCII characters in the test font, using TextOutA Line 7: A line of ASCII/CJK characters in Tahoma In line 4, Windows is providing font substitution for the test font through a Japanese substitution font (deduced from unified Han character shape), thus displaying all ASCII/CJK characters correctly, despite that there isn't such a rule defined in the registry. Wine failed to do the same. On the other hand, Windows doesn't provide the same font substitution if a completely-ASCII string is TextOut-ed. The CJK characters are chosen to include both unified Han characters with a different shape in each font and non-unified characters for each individual font. Implications: 1. This bug may be related to a few weird CJK script rendering problems. 2. This bug may be related to a few western font rendering problems when CJK fonts are installed. 3. I'm not sure if the issue is even CJK related. Windows could be using similar font substitution for other scripts like Hebrew. -- 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 5

[Bug 60261] New: movavi video editor bug ON STEAM LINUX
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=60261 Bug ID: 60261 Summary: movavi video editor bug ON STEAM LINUX Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: pocomal112(a)codverts.com Target Milestone: --- Distribution: --- CANT LAUNCH MOVAVI VIDEO EDITOR 2025 AND 2026 STEAM VERSION ON LINUX AND I DONT HAVE BUG FILES. PLEASE FIX IT. MOVAVI VIDEO EDITOR STEAM VERSION NOT LAUNCHING -- 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 60092] New: Spotify Fails to Login
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=60092 Bug ID: 60092 Summary: Spotify Fails to Login Product: Wine-staging Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: spamemail392g(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81624 --> http://bugs.winehq.org/attachment.cgi?id=81624 A zip file of two logs, one being an attempt of logging into Spotify via the browser, and another via the QR code When attempting to login on Spotify via either the Open in Browser method or the Scan QR Code method, the Spotify client will fail to login. When selecting Open in Browser, it does not do such, even when pressing "Try Again". When scanning the QR code, Spotify shows the option to pair, but when doing so, the client will completely freeze, and cannot be closed, unless it is killed. -- 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 49029] New: ABBYY FineReader 12 Professional crashes in trial mode
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

https://bugs.winehq.org/show_bug.cgi?id=49029 Bug ID: 49029 Summary: ABBYY FineReader 12 Professional crashes in trial mode Product: Wine Version: 5.7 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msxml6 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation from bug 43454 ("Multiple installers and applications crash on unhandled exception 0x000006ba inside NdrAsyncClientCall (ABBYY FineReader 12 Professional)"). Clicking 'Run Program' (= run app in trial mode) causes a crash. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/ABBYY FineReader 12 $ WINEDEBUG=+seh,+relay,+msxml wine ./FineReader.exe >>log.txt 2>&1 ... 0055:Call ole32.CoCreateInstance(2f815e1c,00000000,00000017,2f815e2c,0032d544) ret=2f7ab6e9 ... 0055:Ret msxml3.DllGetClassObject() retval=00000000 ret=00ad5801 ... 0055:trace:msxml:DOMClassFactory_CreateInstance (nil) {00000000-0000-0000-c000-000000000046} 0x32d460 0055:trace:msxml:DOMDocument_create (60, 0x32d41c) ... 0055:trace:msxml:xmldoc_add_refs (0xf76c2d20)->(1) 0055:trace:msxml:get_domdoc_from_xmldoc returning iface 0x28b3f38 0055:trace:msxml:domdoc_QueryInterface (0x28b3f20)->({00000000-0000-0000-c000-000000000046} 0x32d460) 0055:trace:msxml:domdoc_AddRef (0x28b3f20)->(2) 0055:trace:msxml:domdoc_Release (0x28b3f20)->(1) 0055:trace:msxml:DOMClassFactory_Release (0x28d6120) ref = 0 ... 0055:Ret ole32.CoCreateInstance() retval=00000000 ret=2f7ab6e9 ... 0055:trace:msxml:domdoc_createProcessingInstruction (0x28b3f20)->(L"xml" L"version=\"1.0\" encoding=\"UTF-8\"" 0x32d46c) ... 0055:trace:msxml:node_set_content (0x29856e0)->(L"version=\"1.0\" encoding=\"UTF-8\"") ... 0055:trace:msxml:domdoc_createNode (0x28b3f20)->(0x32d3e0 {VT_INT: 1} L"root" L"http://www.abbyy.com/FineReader/BatchOptions/0" 0x32d468) ... 0055:trace:msxml:domdoc_createNode node_type 1 ... 0055:trace:msxml:domdoc_get_documentElement (0x28b3f20)->(0x32d480) 0055:trace:msxml:create_node type 1 ... 0055:trace:msxml:xmldoc_add_refs (0xf76c2d20)->(2) 0055:trace:msxml:domelem_QueryInterface (0x29856e0)->({2933bf80-7b36-11d2-b20e-00c04f983e60} 0x32d42c) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_Release (0x29856e0)->(1) 0055:trace:msxml:domelem_QueryInterface (0x29856e0)->({2933bf86-7b36-11d2-b20e-00c04f983e60} 0x32d480) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_Release (0x29856e0)->(1) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(3) 0055:trace:msxml:domelem_Release (0x29856e0)->(2) ... 0055:trace:msxml:domelem_setAttribute (0x29856e0)->(L"type" 0x32d400 {VT_BSTR: L""}) ... 0055:trace:msxml:domelem_setAttribute (0x29856e0)->(L"languages" 0x32d400 {VT_BSTR: L"English"}) 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028b8ecc L"English",ffffffff,00000000,00000000,00000000,00000000) ret=f799f4a2 0055:Call ntdll.RtlUnicodeToUTF8N(00000000,00000000,0032d324,028b8ecc,00000010) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=00000008 ret=f799f4a2 0055:Call ntdll.RtlAllocateHeap(00110000,00000000,00000009) ret=f799f4c1 0055:Ret ntdll.RtlAllocateHeap() retval=028d6120 ret=f799f4c1 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028b8ecc L"English",ffffffff,028d6120,00000009,00000000,00000000) ret=f799f4ea 0055:Call ntdll.RtlUnicodeToUTF8N(028d6120,00000009,0032d324,028b8ecc,00000010) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=00000008 ret=f799f4ea 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028310bc L"languages",ffffffff,00000000,00000000,00000000,00000000) ret=f799f3a3 0055:Call ntdll.RtlUnicodeToUTF8N(00000000,00000000,0032d324,028310bc,00000014) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=0000000a ret=f799f3a3 0055:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000b) ret=f799f3c2 0055:Ret ntdll.RtlAllocateHeap() retval=028b5a50 ret=f799f3c2 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028310bc L"languages",ffffffff,028b5a50,0000000b,00000000,00000000) ret=f799f3e3 0055:Call ntdll.RtlUnicodeToUTF8N(028b5a50,0000000b,0032d324,028310bc,00000014) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=0000000a ret=f799f3e3 0055:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf7bd80b2 ip=f7bd80b2 tid=0055 0055:trace:seh:raise_exception info[0]=00000000 0055:trace:seh:raise_exception info[1]=a5317000 0055:trace:seh:raise_exception eax=7d125010 ebx=f7cfb000 ecx=7d12501c edx=a5317000 esi=00000030 edi=0000003f 0055:trace:seh:raise_exception ebp=00000003 esp=0032d370 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010283 0055:trace:seh:call_stack_handlers calling handler at 0x2f7bc908 code=c0000005 flags=0 0055:trace:seh:call_stack_handlers handler at 0x2f7bc908 returned 1 ... wine: Unhandled page fault on read access to A5317000 at address F7BD80B2 (thread 0055), starting debugger... --- snip --- Tidbit: The app installer bundles Microsoft MSXML 6.0 x64 redist installer. >From 'AbbyyMsiLog.txt': --- snip -- ... Get prerequisites... Prerequisites: Z:\home\focht\Downloads\FR12_PE\MSXML\msxml6_x64.msi Checking related Product for UpgradeCode: {5BBED1F8-E6F3-4A02-BC97-26D35BE200CA} Prerequisite MaxUpdateVersion is: 6.10.1129.0 No related products for this UpgradeCode [Setup] Run="C:\windows\system32\msiexec.exe" /i "Z:\home\focht\Downloads\FR12_PE\MSXML\msxml6_x64.msi" /passive /Liwrmo!vepacu "C:\users\focht\Temp\msxml6_x64.log" [Setup] RunExitCode=0 ... --- snip --- Due to the presence of Wine's MSXML 6.0 PE builtins, the redist installer does not overwrite them. Only binaries that don't exist in Wine, such as 'msxml6r.dll' get installed in SysWOW64 and System32 respectively. It wouldn't work anyway as Wine always prefers msxml builtins for good reason. 'winetricks -q msxml6' prevents the crash. $ sha1sum ABBYY_FR12_PRO_TRIAL.exe cd209916f9f13486a6d8f6fc6276eeb761b30803 ABBYY_FR12_PRO_TRIAL.exe $ du -sh ABBYY_FR12_PRO_TRIAL.exe 340M ABBYY_FR12_PRO_TRIAL.exe $ wine --version wine-5.7 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 6

[Bug 60168] New: Reget Deluxe - Vertically truncated menu
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=60168 Bug ID: 60168 Summary: Reget Deluxe - Vertically truncated menu Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81808 --> http://bugs.winehq.org/attachment.cgi?id=81808 Screenshot Reget Deluxe 5.2: https://www.majorgeeks.com/mg/getmirror/reget_deluxe,1.html Vertically truncated menu -- 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 18790] New: Default search does not include resolved bugs
by wine-bugs＠winehq.org Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=18790 Summary: Default search does not include resolved bugs Product: WineHQ Bugzilla Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: download, source Severity: enhancement Priority: P3 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk The default search (the search box at the top of this page) does not include closed bugs (rightly so), but it also does not include resolved bugs. This leads to duplicates that could be avoided. See Bug 18601 - a recent regression that is fixed by the next release, but anyone searching for an open bug for Google Sketchup will not see it unless they choose to run an advanced search, which some users clearly don't. I'm sure this is a simple change to the code. -- 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.

3 10

[Bug 60266] New: Window above a full-screen window is drawn behind it
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=60266 Bug ID: 60266 Summary: Window above a full-screen window is drawn behind it Product: Wine Version: 11.14 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: realmaitreal(a)deadmail.lat Target Milestone: --- Created attachment 81984 --> http://bugs.winehq.org/attachment.cgi?id=81984 Minimal Win32 reproducer (C source, ~130 lines, no dependencies) Overview A window which the application places above a full-screen window in the Win32 z-order is drawn behind it and is invisible, when the application owns its windows from a common owner window, as Delphi applications do. winemac.drv elevates a full-screen window to NSStatusWindowLevel+1 while the application is active. Reordering or attaching an owned window goes through -[NSWindow addChildWindow:ordered:], which resets window levels. The owner window is not itself full-screen, so it stays at NSNormalWindowLevel, and the attach drops the affected windows to that level. Because the window level dominates the window server ordering, those windows are then ordered behind the full-screen window and are never promoted again by -adjustWindowLevels:, which decides which windows are "in front" from that same ordering. That -addChildWindow: resets a window level is not documented by Apple. Electron saves and restores the parent window's level around the call for this reason: https://github.com/electron/electron/pull/38460 Measured here with CGWindowListCopyWindowInfo(): attaching a newly created dialog also dropped an existing sibling window from level 27 to level 0. Steps to Reproduce Build and run the attached reproducer (about 130 lines, plain Win32): i686-w64-mingw32-gcc -O1 -o repro.exe repro.c -lgdi32 -luser32 -mconsole wine repro.exe It creates four windows, mirroring a Delphi application's arrangement: 1) APP - a 1x1 owner window, created first so it stays at the back and is never elevated (Delphi's hidden TApplication window) 2) MAIN - a full-screen window, owned by APP 3) START - an ordinary window, owned by APP 4) SPLASH - the window which must stay visible, owned by APP Click the WHITE window (SPLASH) so the application becomes active without raising the black full-screen window in the z-order. The program then swaps START and SPLASH in the z-order once per second with SetWindowPos(hwnd, HWND_TOP, ...) and prints the resulting Win32 z-order. Actual Results The white window is invisible while the application is active, although the program reports it as the top of the Win32 z-order: win32: SPLASH > START > MAIN > APP CGWindowListCopyWindowInfo() reports MAIN at window level 26 (NSStatusWindowLevel+1) and SPLASH, START and APP at level 0. All four are on the same Space and all are ordered in; the white window is simply drawn underneath. It reappears as soon as the application is deactivated, and is visible in Mission Control, which ignores window levels. Reproduced on 20 of 20 samples. Expected Results The white window should be drawn over the full-screen one. Windows has no notion of a full-screen window in the z-order. Per "Window Features": "The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows." "A child window is grouped with its parent in z-order." Position in the z-order is therefore determined by window type, not by a window's size, so a window which happens to cover the screen has no special standing. SetWindowPos() with HWND_TOP "Places the window at the top of the Z order", and after that call the window must not remain obscured. https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setw… Build Date & Hardware wine-11.14, macOS 26.6.2 (Darwin 25.6.0), Apple Silicon running the x86_64 build. -addChildWineWindow:, -setChildWineWindows: and -adjustWindowLevels: are byte-identical in 11.16 and in current master, so those are affected too. Additional Information Found with OMSI 2 (Steam appid 252530): the loading form is invisible for the whole of a map load, leaving a black screen, and the "really quit?" dialog is invisible as well. Both reappear if the application is deactivated and reactivated. The application must be active for the bug to appear, because the elevation only applies while it is. The similar reports Bugzilla suggests (13515, 22944, 31370, 35384, 56021, 58537, 59334) are all on Linux; none is against winemac.drv. -- 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 60265] New: d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=60265 Bug ID: 60265 Summary: d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d2d Assignee: wine-bugs(a)list.winehq.org Reporter: werner.bundschuh(a)pm.me Target Milestone: --- Distribution: --- Created attachment 81981 --> http://bugs.winehq.org/attachment.cgi?id=81981 Standalone reproducer (build with mingw, see bug description) # d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes ## Summary `d2d_geometry_resolve_beziers()` subdivides overlapping bezier control triangles until they no longer overlap. When the underlying curves genuinely cross -- or when several nodes sit on (nearly) the same coordinates -- subdividing never separates them, and the loop only terminates once the control points become collinear in float precision. Every split appends a segment that is then tested against all earlier ones, so the segment count grows combinatorially. On a real world document this exhausts memory instead of finishing. ## Affected code `dlls/d2d1/geometry.c`, `d2d_geometry_resolve_beziers()`, first phase: /* Split overlapping bezier control triangles. */ while (d2d_geometry_get_next_bezier_segment_idx(geometry, &idx_p)) { d2d_geometry_get_first_bezier_segment_idx(geometry, &idx_q); while (idx_q.figure_idx < idx_p.figure_idx || idx_q.vertex_idx < idx_p.vertex_idx) { while (d2d_geometry_check_bezier_overlap(geometry, &idx_p, &idx_q)) { ... d2d_geometry_split_bezier(geometry, &idx_q or &idx_p); } d2d_geometry_get_next_bezier_segment_idx(geometry, &idx_q); } } Unchanged since 2187a1edb ("d2d1: Split overlapping bezier control triangles.", Henri Verbeet, 2017, Wine 2.15). The only termination condition is in `d2d_geometry_check_bezier_overlap()`: if (d2d_point_ccw(a[0], a[1], a[2]) == 0.0f || d2d_point_ccw(b[0], b[1], b[2]) == 0.0f) return FALSE; That is float exhaustion, not an algorithmic bound. ## Measurements Instrumenting the loop to record the subdivision depth per segment, on the attached reproducer: segments start end max depth avg depth 20 220 1544 25 5.51 40 872 2336 25 3.91 80 3312 14948 25 4.82 160 14144 54057 25 4.18 The maximum depth is exactly 25 in every run -- the point at which halving a control triangle with coordinates around 500 no longer changes the float32 mantissa. The average depth is 4 to 5.5, so only a small tail of pairs runs all the way down; those are the pairs whose curves actually cross. Wall clock for `ID2D1GeometrySink::Close()` on the reproducer, Wine 11.16 release build, measured A/B/A/B interleaved on an otherwise unchanged machine (medians; the two runs per variant agree within 3%): segments unpatched patched factor 20 39.2 ms 20.9 ms 1.87 40 85.1 ms 56.7 ms 1.50 80 3114.2 ms 1844.2 ms 1.69 160 42132.9 ms 28794.4 ms 1.46 Note that the reproducer is dominated by the overlap tests, not by the array shifting, so it mostly exercises the subdivision bound. The array shifting is what dominates in the real world case below, where the unpatched version does not finish at all and no ratio can be given. ## Real world case Affinity Designer 3 (via Wine) freezes when selecting a specific object in a customer document. The object contains a cluster of nodes at practically identical coordinates. Sampled with gdb, 30 samples over three minutes, 100% of the time is in `memmove` reached through: d2d_geometry_sink_Close -> d2d_geometry_resolve_beziers -> d2d_geometry_split_bezier -> d2d_figure_insert_vertex -> memmove The figure had grown to roughly 915,000 vertices and was still growing by about 23,000 per minute after eight minutes; each insertion memmoves 1.3 to 6.5 MB. The operation never completes. ## Two independent problems 1. `d2d_geometry_split_bezier()` inserts into the middle of the figure's vertex, vertex type and control arrays. That is O(n) per split, so the phase is O(splits * vertices) -- this is what dominates in the real world case. The splitting phase only ever reads three points per segment (`d2d_geometry_check_bezier_overlap`, `d2d_geometry_bezier_ccw`), so the array bookkeeping is not needed until the phase ends. 2. The number of splits is not bounded by anything except float precision. ## Reproducer `repro.c` (attached) builds a closed path of N quadratic bezier segments whose control points sit near the centre, so the control triangles overlap, and times `ID2D1GeometrySink::Close()`. No render target is needed. Build with mingw: x86_64-w64-mingw32-gcc -O2 -o repro.exe repro.c -ld2d1 -lole32 -lm ## Notes Also observed while reading this code, not addressed here: the middle loop condition while (idx_q.figure_idx < idx_p.figure_idx || idx_q.vertex_idx < idx_p.vertex_idx) is an OR where lexicographic ordering is intended. It happens to be safe only because q always meets p exactly; the return value of the following `d2d_geometry_get_next_bezier_segment_idx()` is not checked, so if q ever ran past p the loop would index `figures[figure_count]`. -- 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