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

[Bug 60116] SuperTux Advanced 0.2.55 shows an error message on start (File not found or cannot be read! (cannot open the file))

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60116 --- Comment #1 from Tobias (:Tobbi) Markus <tobbi.bugs(a)googlemail.com> --- Created attachment 81672 --> http://bugs.winehq.org/attachment.cgi?id=81672 log -- 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.

Aug. 2, 2026

[Bug 60105] Crossrunner emulator crashes on loading a hard drive image file

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60105 --- Comment #3 from ruby R53 <enkiferreiracosta867(a)gmail.com> --- just tried this on 4dbf7be and the bug remains, with the program behaving the same exact way as the one i have from my distro's repositories and with the same exact build options -- 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.

Aug. 2, 2026

[Bug 60116] New: SuperTux Advanced 0.2.55 shows an error message on start (File not found or cannot be read! (cannot open the file))

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60116 Bug ID: 60116 Summary: SuperTux Advanced 0.2.55 shows an error message on start (File not found or cannot be read! (cannot open the file)) Product: Wine Version: 11.14 Hardware: x86-64 URL: https://kelvinshadewing.itch.io/supertux-advance OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: tobbi.bugs(a)googlemail.com Target Milestone: --- % ./wine --version wine-11.14-98-g4dbf7bef7a0 % openssl sha256 sta-0.2.55.zip SHA2-256(sta-0.2.55.zip)= b63139bef5b99ad4a6cc7900206a295e59e7e1389756704163cf59b23b201780 I noticed that SuperTux Advanced 0.2.55 does not start properly and gives the following error message: ================ Running ... Error running '': Squirrel exception: File not found or cannot be read! (cannot open the file) ================ Steps to reproduce: 1. Download SuperTux Advanced 0.2.55 from the website mentioned. 2. Extract the downloaded file. 3. Run SuperTux Advanced through ./wine sta/sta.exe Expected results: SuperTux Advanced run. Actual results: SuperTux Advanced can't find a file and closes. I ran the application on a Windows 10 VM where it works 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.

Aug. 2, 2026

[Bug 60114] Client fails to find shared session objects after the session mapping has grown, window class registration fails with error 1411

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60114 --- Comment #1 from Seth2313(a)gmail.com <Seth2313(a)gmail.com> --- Clarification on the scope of the evidence, so that nobody over-reads the original description. The failure was observed and analysed on a single occasion (2026-06-03), and that is where the quoted WINEDEBUG line comes from. Since then the patched wineserver with the larger initial mapping has been in place for practically all use of this setup, so the failure has had little opportunity to recur. "Makes the failure disappear permanently" in the original description should therefore be read as "has not been seen again while the larger initial mapping was in place". It is not the result of a controlled A/B comparison, and I want that stated plainly rather than implied. What this does not change is the log evidence itself: NtUserRegisterClassExWOW had already completed the create_class server call successfully and received a valid locator, and only the client-side find_shared_session_object() lookup failed. That is a direct observation from the log, not an inference from the workaround. If a reproduction with a stock wineserver plus WINEDEBUG=warn+win32u,+class would help triage, I am happy to produce one. It should show whether find_shared_session_block() fails to map the block covering the offset, or whether the id check in find_shared_session_object() mismatches. -- 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.

Aug. 2, 2026

[Bug 60115] New: d2d_cdt_insert_segment() recurses without a global termination guard, stack overflow on degenerate geometry

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60115 Bug ID: 60115 Summary: d2d_cdt_insert_segment() recurses without a global termination guard, stack overflow on degenerate geometry Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d2d Assignee: wine-bugs(a)list.winehq.org Reporter: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS An application that draws complex vector graphics through Direct2D can kill Wine's main thread. A helper function in Wine's Direct2D triangulation code calls itself over and over without ever stopping when the input geometry is degenerate, until the 1 MB thread stack is used up and the process dies with a stack overflow. There is a safety check in the function, but it only guards a single call level, so it never fires. SUMMARY d2d_cdt_insert_segment() in dlls/d2d1/geometry.c:2287 recurses without a global termination guard. For degenerate geometry (collinear or duplicate vertices) the recursion oscillates between two origins and never terminates, exhausting the thread stack: EXCEPTION_STACK_OVERFLOW (0xC00000FD). The application's main thread dies while its audio threads keep running, so the process turns into a half-alive zombie rather than exiting. ENVIRONMENT Wine: wine-staging 11.9 when analysed; the affected code is byte-identical in 11.13 Application: FL Studio (64-bit) with two or more Serum 2 instances (JUCE/IPlug GUI drawing via Direct2D) d2d1: Wine builtin THE DEFECT static BOOL d2d_cdt_insert_segment(struct d2d_cdt *cdt, struct d2d_geometry *geometry, const struct d2d_cdt_edge_ref *origin, struct d2d_cdt_edge_ref *edge, size_t end_vertex) { for (current = *origin;; current = next) { ... if (<collinear case>) { d2d_cdt_edge_sym(&new_origin, &current); return d2d_cdt_insert_segment(cdt, geometry, &new_origin, edge, end_vertex); /* :2312 */ } if (d2d_cdt_rightof(...) && d2d_cdt_leftof(...)) { ... new_origin = *edge; return d2d_cdt_insert_segment(cdt, geometry, &new_origin, edge, end_vertex); /* :2335 */ } if (next.idx == origin->idx) { ERR("Triangle not found.\n"); return FALSE; } } } The only termination guard is "next.idx == origin->idx", which detects a full revolution around THE ORIGIN OF THE CURRENT INVOCATION. Both recursive calls at :2312 and :2335 enter with a NEW origin, so each level starts its guard from scratch. When the traversal cycles between two origins (A -> B -> A -> ...), no level ever completes a revolution, the guard never triggers, and the recursion is unbounded. EVIDENCE 1. Stack overflow (original code). With WINEDEBUG=+seh: code=c00000fd ... stack 0x108c0 (0x10000-0x11000-0x110000) i.e. the 1 MB thread stack is fully consumed. The main thread dies; the process stays alive because its audio threads are unaffected, which presents to the user as a total UI freeze. 2. The non-termination is real, not merely deep recursion. Both recursive calls are tail calls, so they can be rewritten as a loop ("origin = &new_origin; goto restart;") without any change in semantics. With that rewrite the stack overflow disappears and is replaced by an INFINITE LOOP: the thread spins at 100 % CPU with the instruction pointer stable inside d2d_cdt_insert_segment (RVA 0x2e9a3), confirmed with gdb across many samples. That rules out "recursion is merely too deep" and establishes non-termination. WORKAROUND IN USE HERE Tail-call elimination plus a generous iteration budget, bailing out the same way the existing "Triangle not found" path does: --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ struct d2d_cdt_edge_ref base_edge, current, new_origin, next, target; size_t current_destination, current_origin; + unsigned int iterations = 0; +restart: for (current = *origin;; current = next) { + /* Guard against non-terminating cycles caused by degenerate geometry + * (e.g. collinear/duplicate vertices). The original code recursed here + * and died with a stack overflow; bail out and skip the segment instead. + * A correct segment insertion is O(edge_count), so a generous multiple + * of it is a safe upper bound that legitimate geometry never reaches. */ + if (++iterations > 16 * cdt->edge_count + 0x10000) + { + WARN("Iteration limit exceeded, skipping segment.\n"); + return TRUE; + } with both "return d2d_cdt_insert_segment(...)" calls replaced by "origin = &new_origin; goto restart;". This has been in daily production use since 2026-05 with no visible rendering artefacts. Note this returns TRUE (skip the segment and carry on) rather than FALSE. FALSE propagates up through d2d_cdt_insert_segments() and fails the whole tessellation, which in practice loses far more than the one bad segment. Which of the two is the right upstream behaviour is a call for the d2d1 maintainers - the important part is that the function must terminate. NO MINIMAL REPRODUCER The degenerate geometry is produced at runtime by a closed-source plugin GUI, so I cannot supply a small test case. A targeted test would presumably construct a path geometry containing duplicate and collinear vertices and tessellate it. I am happy to test any candidate patch against the real workload that triggers this reliably. -- 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.

Aug. 2, 2026

[Bug 60114] New: Client fails to find shared session objects after the session mapping has grown, window class registration fails with error 1411

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60114 Bug ID: 60114 Summary: Client fails to find shared session objects after the session mapping has grown, window class registration fails with error 1411 Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS Wine keeps user interface objects (window classes, windows, message queues) in a shared memory area that starts small and is supposed to grow as needed. Once it actually has to grow, the application side can no longer find objects that the wineserver created successfully just before - window class registration then fails with error 1411 and the application aborts. Making the area large enough that it never has to grow avoids the problem entirely, which is what points at the growth path as the culprit. SUMMARY After the shared session mapping has had to grow beyond its initial size, the CLIENT can no longer resolve session objects the SERVER has successfully allocated: find_shared_session_object() returns NULL although the server request succeeded and returned a valid locator. Window class registration then fails with ERROR_CLASS_DOES_NOT_EXIST (1411). Raising only the INITIAL size of the session mapping in server/mapping.c:create_session_mapping() from 512 to 32768 object_shm_t slots avoids the growth path entirely and makes the failure disappear permanently. ENVIRONMENT Wine: wine-staging 11.13 (also 11.9, 11.10, 11.11, 11.12) Application: FL Studio 2025 / 2026 (64-bit), large projects with many plugin instances Kernel: 7.1.3 (CachyOS), ntsync in use STEPS TO REPRODUCE 1. Run FL Studio with a stock wineserver. 2. Load a project large enough to create several thousand user objects (window classes, windows, message queues) - in practice a project with many plugin windows. 3. Loading fails with error 1411. Actual result: error 1411; in our case followed by an abort inside the application (c0000409). Expected result: project loads; the session mapping grows transparently. EVIDENCE: THE FAILURE IS ON THE CLIENT SIDE WINEDEBUG output at the moment of failure: err:class:NtUserRegisterClassExWOW Failed to get shared session object for window class That ERR is emitted in dlls/win32u/class.c:656, and the code path matters: SERVER_START_REQ( create_class ) { ... ret = !wine_server_call_err( req ); locator = reply->locator; /* server succeeded, locator valid */ atom = reply->atom; } SERVER_END_REQ; if (!ret) goto failed; /* not taken - server call was fine */ if (!(shared = find_shared_session_object( locator.id, locator.offset ))) { ERR( "Failed to get shared session object for window class\n" ); So the server allocated the object and returned its locator; only the client-side lookup in find_shared_session_object() (dlls/win32u/winstation.c:175) failed. It fails either because find_shared_session_block() could not map a block covering locator.offset, or because the id check "id == shared_object_get_id( object )" did not match. WHY THIS POINTS AT THE GROWTH PATH * Server side, the mapping is explicitly designed to grow: alloc_shared_object() -> find_free_session_block() -> grow_session_mapping() in server/mapping.c, which enlarges the backing file and maps the additional region. * Client side, find_shared_session_block() (dlls/win32u/winstation.c:145) walks the list of already mapped blocks and otherwise calls map_shared_session_block(), which re-opens \KernelObjects\__wine_session and maps a view at the granularity-aligned offset. * A larger INITIAL size cannot change any of this logic - it only ensures the growth path is never taken. That it reliably fixes the failure is the strongest indication that the defect lives in growing the mapping or in the client picking the growth up. One detail I noticed while reading, possibly harmless but it looks wrong: LIST_FOR_EACH_ENTRY( block, &session_blocks, struct session_block, entry ) if (block->offset < offset && offset + size <= block->offset + block->size) The first comparison is strict, so an object located exactly at block->offset is not recognised as covered by that block and an additional view gets mapped. "<=" looks like the intended comparison. WORKAROUND CURRENTLY IN USE --- a/server/mapping.c +++ b/server/mapping.c @@ -1425,7 +1425,7 @@ unsigned int attr, const struct security_descriptor *sd ) { static const unsigned int access = FILE_READ_DATA | FILE_WRITE_DATA; - size_t size = max( sizeof(*shared_session) + sizeof(object_shm_t) * 512, 0x10000 ); + size_t size = max( sizeof(*shared_session) + sizeof(object_shm_t) * 32768, 0x10000 ); size = round_size( size, host_page_mask ); return create_mapping( root, name, attr, size, SEC_COMMIT, 0, access, sd ); In continuous daily use across five Wine releases (11.9 -> 11.13) without any observed side effect. It requires rebuilding wineserver from matching sources after every Wine update, which is why a proper fix would be very welcome. RULED OUT BY TESTING ntsync, esync/fsync settings, and Wine version updates - the failure follows the session pool size and nothing else. AVAILABLE ON REQUEST A full WINEDEBUG=warn+win32u,+class log from a reproduction with the stock wineserver. The interesting lines would be "Failed to map session block for offset ..." from find_shared_session_block(), which would distinguish "could not map the block" from "id mismatch". Say the word and I will produce it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 2, 2026

[Bug 60113] New: Deadlock between winex11.drv/Xlib and the OpenGL driver lock hangs multi-threaded GL application

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60113 Bug ID: 60113 Summary: Deadlock between winex11.drv/Xlib and the OpenGL driver lock hangs multi-threaded GL application Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS Two threads of the same application block each other forever. One of them is inside Wine's X11 code and needs the graphics driver; the other is inside the graphics driver and is waiting for an answer from the X server - an answer that has already arrived, but that only the first thread could pick up. Neither can move, the application hangs for good. The X server itself is perfectly healthy the whole time. SUMMARY Deadlock between winex11.drv/Xlib and the OpenGL driver's internal lock: a multi-threaded application using OpenGL hangs permanently, with the main thread holding an X11-related lock while blocked on the GL driver lock, and a second thread holding the GL driver lock while waiting for an X reply that can no longer be delivered. ENVIRONMENT Wine: wine-staging 11.13 (also seen on 11.9-11.12) Application: FL Studio 2026 (64-bit), Image-Line. OpenGL is loaded dynamically via LoadLibrary("opengl32.dll") GPU driver: NVIDIA 610.43.03 (open modules) Display: XWayland 24.1.13 under KWin 6.7.3 (KDE Plasma Wayland session) Kernel: 7.1.3 (CachyOS), ntsync in use Sync: WINEESYNC=1 WINEFSYNC=1, __GL_THREADED_OPTIMIZATIONS=0 Note that __GL_THREADED_OPTIMIZATIONS=0 was already set, so the NVIDIA threaded-optimization helper thread is NOT involved. SYMPTOM The application freezes completely and can normally only be terminated with "wineserver -k". The X server itself stays healthy the entire time and answers other clients immediately. This has occurred repeatedly over months; the analysis below is from one instance that was caught while still running. MEASURED STATE DURING THE HANG All 137 threads were parked; no thread in state R; zero CPU progress over several seconds. --- Thread A - main thread (TID == PID) --- /proc/PID/task/TID/syscall: 202 (futex) uaddr=0x7f0313fe58a0 op=0x80 (FUTEX_WAIT|PRIVATE) val=2 timeout=NULL pthread_mutex_t at 0x7f0313fe58a0, read from /proc/PID/mem: __lock=2 __count=1 __owner=19561 __nusers=1 __kind=1 (PTHREAD_MUTEX_RECURSIVE) Stack, obtained by scanning $rsp against the process mappings - gdb produces only "?? ()" for Wine processes. Innermost first: libc.so.6 <- libnvidia-glcore <- libGLX_nvidia <- libnvidia-glcore <- libGLX_nvidia <- libGL.so.1 <- libGLX_nvidia <- libGLX.so.0 <- libX11.so.6 <- libGLX.so.0 <- libX11.so.6 <- libGL.so.1 <- winex11.so <- win32u.so <- opengl32.so <- ntdll.so <- opengl32.dll Thread A additionally HELD a second, uncontended lock: 0x7f03e04d6240 __lock=1 __owner=<TID of thread A> __kind=0 (PTHREAD_MUTEX_NORMAL) in an anonymous mapping adjacent to winex11.so. I could not resolve this to a symbol - addresses are process-local and the process has since been restarted. --- Thread B - TID 19561, thread name "SmoothAnimation" --- /proc/PID/task/19561/syscall: 202 (futex) uaddr=0x5555946a1ce4 op=0x189 (FUTEX_WAIT_BITSET|PRIVATE|CLOCK_REALTIME) val=254 timeout=NULL val3=0xffffffff op=0x189 with FUTEX_BITSET_MATCH_ANY is glibc's pthread_cond_wait; the address is in [heap]. Stack: libc.so.6 <- libX11.so.6 <- libc.so.6 <- libGLX_nvidia <- libnvidia-glcore <- libGLX_nvidia <- libGLX.so.0 <- win32u.so <- winex11.so <- win32u.so <- opengl32.so <- ntdll.so <- opengl32.dll Thread B HELD the recursive mutex thread A was waiting for, plus a second recursive mutex at 0x7f023424f2c0 (__lock=1, __count=1) located in the mapping range of libGL.so.1 / libGLX.so.0, i.e. the GLX dispatch lock. --- X connection --- "ss -x -p" on the application's X11 socket showed 200 bytes sitting UNREAD in the receive queue while the process was hung. The X server was fully responsive to other clients (xdpyinfo from another process returned immediately). THE CYCLE Thread A (main): holds X11/winex11-related lock -> blocks acquiring GL driver lock Thread B: holds GL driver lock + GLX lock -> waits inside libX11 for an X reply The reply bytes had already arrived from the X server but nobody consumed them: the thread that would have dispatched them is thread A, which is blocked inside the GL driver. VERIFICATION OF THE DIAGNOSIS Releasing the GL driver mutex on thread B's behalf - writing __lock=__count=__owner=__nusers=0 and issuing FUTEX_WAKE - immediately resolved the hang: thread A acquired the mutex through the normal glibc path, the X socket receive queue drained to 0, thread B woke up, and the application continued running normally for over an hour afterwards. This confirms the cycle above rather than an external X stall. This is of course not a fix, just a demonstration. Thread B then continues without the lock it believes it holds; its later pthread_mutex_unlock fails cleanly with EPERM because glibc checks __owner. ANALYSIS / SUGGESTED DIRECTION winex11.drv appears to call into the GL/GLX stack while holding an internal lock that is also required to dispatch X replies. The GL driver in turn performs an X round trip while holding ITS lock. That is a lock-order inversion between two components that know nothing about each other, so it can only be resolved on the Wine side - e.g. by not holding the display/driver lock across calls into libGL, or by giving GL round trips a separate X connection. NOT AVAILABLE I do not have a minimal reproducer. The hang occurs sporadically in a large commercial application. The diagnostic path above is fully scriptable, though, so anyone hitting a similar hang can confirm the pattern in a few seconds: 1. cat /proc/PID/task/TID/syscall for the main thread -> futex address 2. read 20 bytes at that address from /proc/PID/mem -> __owner gives the holding TID. Works for PTHREAD_MUTEX_RECURSIVE and ERRORCHECK; NORMAL mutexes store no owner. 3. repeat for the holder to follow the chain Requires kernel.yama.ptrace_scope=0. I am happy to test any candidate patch against the workload that triggers this. -- 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.

Aug. 2, 2026

[Bug 58180] CaptureAge 1.17.1: fails to GetSharedHandle

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58180 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #2 from Stian Low <wineryyyyy(a)gmail.com> --- MR-11404 in process to support GetSharedHandle: - https://gitlab.winehq.org/wine/wine/-/merge_requests/11404#note_147541 Unity games are widely bugged without GetSharedHandle which seems to be used with D3D11_CREATE_DEVICE_VIDEO_SUPPORT. Attached logs are incomplete so unable to confirm if CaptureAge also uses D3D11_CREATE_DEVICE_VIDEO_SUPPORT which has a workaround via MR-11398 which forces UnityPlayer to skip GetSharedHandle method of rendering: - https://gitlab.winehq.org/wine/wine/-/merge_requests/11398 I'll test CaptureAge for latest wine with patches which may apply. -- 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.

Aug. 2, 2026

[Bug 58325] wined3d swapchain use-after-free

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58325 --- Comment #12 from Stian Low <wineryyyyy(a)gmail.com> --- Seems duplicate: - https://bugs.winehq.org/show_bug.cgi?id=58657 -- 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.

Aug. 2, 2026

[Bug 58657] Reference to swapchain not removed when swapchain is destroyed

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58657 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #1 from Stian Low <wineryyyyy(a)gmail.com> --- May be related or duplicate of: - https://bugs.winehq.org/show_bug.cgi?id=58325 -- 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.

Aug. 2, 2026