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

[Bug 59333] New: VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC)
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59333 Bug ID: 59333 Summary: VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: lina(a)lina.yt Distribution: --- Created attachment 80270 --> http://bugs.winehq.org/attachment.cgi?id=80270 Debug & gdb logs VNyan (https://suvidriel.itch.io/vnyan) under recent versions of Wine starts leaking memory at a random time (from minutes to hours after startup). It took a few days of debugging and reverse engineering, but I tracked this down to an issue with Unity's GC observing a weird stack switch in Wine. For reference, Proton 8-5 seems to be fine and GE Proton 10-15 triggers the problem. The problem reproduces with plain `wine-11.0 (Staging)` (wine-11.0-2.fc43.x86_64 from Fedora 43), which is what I used for the traces in this bug. This is the Win32 threads code in the Unity fork of bdwgc: https://github.com/Unity-Technologies/bdwgc/blob/unity-master/win32_threads… Normally, bdwgc will use SuspendThread() on all application threads (see GC_suspend()) and then call GetThreadContext() to retrieve the thread context. It then uses the sp value to determine which stack segment to mark as roots for GC. The logic is complex and there is a safety check in case sp is out of bounds (then it collects the whole stack). However, on line 1695 above, sp is blindly subtracted from thread->stack_base and used to compute the stack usage in bytes, without any bounds checks. This means that when sp ends up above the stack, the subtraction overflows and returns a bogus huge stack size. This ends up throwing off the GC collection threshold, and the GC never runs again. During a normal stop-the-world GC ([1] in vnyan_debug.txt), all threads are stopped with $rip in Windows code (0x00006fffffxxxxxx) (other than the main thread which is in 0x000000018xxxxxx because I patched the Mono DLL to not relocate, for consistent debugging). Most threads are in NtWaitForSingleObject or NtWaitForAlertByThreadId, a couple in NtDelayExecution/NtNotifyChangeKey/NtUserMsgWaitForMultipleObjectsEx/NtWaitForMultipleObjects, and two threads in a mmdevapi wine_unix_call(). When the bug occurs, one thread is caught in the middle of UNIX code ([2] in vnyan_debug.txt). The stack pointer changes from this (pre-bug): Thread 82 (Thread 32.0x2c0): $201 = 0x7a8bf3e8 To this (during bug): Thread 82 (Thread 32.0x2c0): $295 = 0x12938eab0 The GC logs this warning (needs patches to enable debug logs): --> Marking for collection #2607 after 3617216 allocated bytes Marked from 150 dirty pages GC Warning: Thread stack pointer 000000012938EAB0 out of range, pushing everything Pushed 34 thread stacks And then the GC stops working. In the particular repro logged, rip is pointing here in __wine_syscall_dispatcher (it's usually within a few instructions of this area): https://github.com/wine-mirror/wine/blob/db11d0fe6a169c457e23d007e20404643d… This means that is_inside_syscall() returned false and allowed the thread state to be captured directly from native thread state. This is defined as: static inline BOOL is_inside_syscall( ULONG_PTR sp ) { return ((char *)sp >= (char *)ntdll_get_thread_data()->kernel_stack && (char *)sp <= (char *)get_syscall_frame()); } Just a few lines before the instruction the thread was stopped in: "leaq 0x70(%rcx),%rsp\n\t" /* %rsp > frame means no longer inside syscall */ Indeed, %rsp as seen by the user app is 0x70 into syscall_frame (which is 0x12938ea40). Later in the function the stack is switched to the proper user stack: /* switch to user stack */ "movq 0x88(%rcx),%rsp\n\t" I believe when a thread is stopped in the entire range between those two instructions, user code can observe %rsp set to a bogus value that should not be possible. This code was moved around by commit 245e8cedf059 and previously introduced by 0a5f7a71036. I'm not sure why %rsp is being set to point into &frame->rip instead of simply restoring it to the user stack pointer earlier. -- 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 44

[Bug 59446] New: Latest VOCALOID6 version (6.11) crashes after VOCALOID:AI track
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59446 Bug ID: 59446 Summary: Latest VOCALOID6 version (6.11) crashes after VOCALOID:AI track Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: dominikgx(a)gmail.com Distribution: --- Created attachment 80430 --> http://bugs.winehq.org/attachment.cgi?id=80430 crash log I ran both VOCALOID and voicebank library installers. Afterwards: 'winetricks corefonts cjkfonts dotnet48' (Both corefonts and dotnet48 are neccessary. cjkfonts is optional for EULA text) to install dependencies. The program starts, but unfortunately it crashes as soon as I create an AI track. Adding dotnetdesktop6 or 8, d3dcompiler_47, mf, quartz, win10 using winetricks, did not work. Please look into this crash. -- 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 15346] New: Winamp disappears when you move it's location
by wine-bugs＠winehq.org Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=15346 Summary: Winamp disappears when you move it's location Product: Wine Version: 1.1.5 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: homerhomer(a)gmail.com Created an attachment (id=16178) --> (http://bugs.winehq.org/attachment.cgi?id=16178) DwmSetWindowAttribute error Sort of a silly bug, basically once winamp is up and running, if you click on the title bar and move it around winamp disappears. To make sure that the bug happens make sure to swirl it around a couple of times. ( A Swirly if you will ) Attached I also noticed this when running winamp manually at startup. This may be related. but then I move winamp and it disappears I don't get any more error messages. So I'm not sure. I appreciate the good work Thank you I'm running Ubuntu 8.04, Wine 1.1.5, AMD64 -- 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 48

[Bug 49583] New: Assassin's Creed Odyssey displays black bars on top and bottom.
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=49583 Bug ID: 49583 Summary: Assassin's Creed Odyssey displays black bars on top and bottom. Product: Wine Version: 5.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: GloriousEggroll(a)gmail.com Distribution: --- Created attachment 67739 --> https://bugs.winehq.org/attachment.cgi?id=67739 AC Odyssey black bar fix It's been a long known issue that AC: Odyssey renders with black bars on the top and bottom of the screen (see screenshot 1). Derek Lesho came up with a stub patch that both fixed this -and- allowed STEEP to run (it would not display previously). That patch can be found here: https://github.com/GloriousEggroll/proton-ge-custom/blob/5.12-GE-1/patches/… Recently, the relevant function QueryDisplayConfig was implemented, however it did not contain some of the changes Derek's patch adds. This allowed steep to work, however AC: Odyssey still retained the black bar issue. I modified Derek's patch by adding the relevant parts to QueryDisplayConfig, and removing the relevant flag checks (Derek's patch did this previously), and this allowed AC: Odyssey to render properly without the black bars. (see screenshot 2). The patch is hacky but may provide more information towards fixing this 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.

2 9

[Bug 59452] New: I tried using the vpn provider called swifttunnel on linux but it just wouldnt open at all
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59452 Bug ID: 59452 Summary: I tried using the vpn provider called swifttunnel on linux but it just wouldnt open at all Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: neil.patilalt(a)gmail.com Distribution: --- Created attachment 80440 --> http://bugs.winehq.org/attachment.cgi?id=80440 it has the backtrace of the vpn provider named swifttunnel that works on windows but i tried on linux and it just crashed it just crashed as soon as i tried to open the program -- 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 58325] New: wined3d swapchain use-after-free
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=58325 Bug ID: 58325 Summary: wined3d swapchain use-after-free Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: yshuiv7(a)gmail.com Distribution: --- Releasing the swapchain brings us to wined3d_swapchain_cleanup, which destroys the front/back buffer textures. Texture destruction is async, happening on the device's command stream. This means these textures can be destroyed way after the swapchain itself. But we did set `texture->swapchain` to `NULL` before queuing their destruction, so that bit is fine. The problem is in texture_resource_unload. Here we try to acquire the context, which goes adapter_gl_acquire_context -> wined3d_context_gl_acquire -> wined3d_context_gl_activate -> wined3d_context_gl_update_window. And here we try to access `context_gl->c.swapchain->win_handle`, which unfortunately points to the swapchain that was just freed. I am unsure what's the fix for this. Do we hold a refcount of the swapchain in the context? Do we clear `context->swapchain` when a swapchain is being freed? Should we release the front/back buffer synchronously? Or something else? -- 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 59432] New: MediaFoundation does not set D3D11_RESOURCE_MISC_FLAG for textures
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59432 Bug ID: 59432 Summary: MediaFoundation does not set D3D11_RESOURCE_MISC_FLAG for textures Product: Wine Version: 11.2 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Created attachment 80406 --> http://bugs.winehq.org/attachment.cgi?id=80406 Log of game from Steam with +d3dkmt,+mfplat,+quartz System: MacBook Pro M1 (2020), macOS 14.1.1, Wine Staging 11.2, DXMT 0.73 When using DXMT as the renderer, a Shared Handle is created through D3DKMT for video textures. However when games (especially Unity games) try to use video rendering, the videos along with audio simply do not work. According to 3Shain, the current implementation of MediaFoundation has an issue where a miscflag (D3D11_RESOURCE_MISC_FLAG) does not get set, and as such DXMT fails to render anything. So I only hear audio and no video. Logs from Unity game's (In Falsus), startup video is given. -- 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 45882] New: (Overwatch, several source games) Raw Mouse input not working
by wine-bugs＠winehq.org Feb. 24, 2026

Feb. 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=45882 Bug ID: 45882 Summary: (Overwatch, several source games) Raw Mouse input not working Product: Wine Version: 3.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: florian98.rg(a)gmail.com Distribution: --- Playing Overwatch I've noticed that the game still uses mouse pointer speed even though on Windows it uses Raw Mouse input exclusively. I've tried this on any branch of Wine (staging, esync, whatsoever) and the problem still persists. This also happens in Valve games where you can enable Raw Mouse Input, e.g. Team Fortress 2 etc. This does not happen with the native ports of said games that use SDL to get mouse input. I already disabled any mouse acceleration in GNOME whatsoever (using the "Flat" Profile), however the problem persists. Is it possible to rewrite Wine to get Mouse input via SDL2 instead? That would help pave way for Wayland etc. Thanks -- 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 34

[Bug 46534] New: Just Cause 4 crashes on startup
by wine-bugs＠winehq.org Feb. 24, 2026

Feb. 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=46534 Bug ID: 46534 Summary: Just Cause 4 crashes on startup Product: Wine Version: 4.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ramy0zahran(a)gmail.com Distribution: --- Created attachment 63387 --> https://bugs.winehq.org/attachment.cgi?id=63387 JC4backtrace Unhandled exception: page fault on read access to 0xffffffffffffffff in 64-bit code (0x0000000141926167). -- 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 19

[Bug 59414] New: AAC error when playing Unity game videos
by WineHQ Bugzilla Feb. 24, 2026

Feb. 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59414 Bug ID: 59414 Summary: AAC error when playing Unity game videos Product: Wine Version: 11.2 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: msdmo Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Created attachment 80382 --> http://bugs.winehq.org/attachment.cgi?id=80382 Video playback after enabling DisableGstByteStreamHandler System: MacBook Pro M1 (2020), macOS 14.1.1, Wine Staging 11.2, DXMT 0.71 (I downgraded from 0.73 due to it having Shared Handle issues) Related to MR 6442 When playing a Unity game (in this case, Hollow Knight Silksong), any video renders unsmoothly and poorly compared to what it should look like. I see the following in the logs: (wine:64457): GStreamer-Video-CRITICAL **: 08:23:38.263: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed 058c:fixme:mfplat:media_source_get_service_GetService Unsupported service {dd0ac3d8-40e3-4128-ac48-c0add067b714}. But this is an old issue. And only sometimes video playback works just fine. When enabling DisableGstByteStreamHandler OR using MR 5988, I get the following error with no video/audio: ``` 0:00:00.651204750 65255 0x600001b395c0 ERROR aacparse gstaacparse.c:355:gst_aac_parse_sink_setcaps:<aacparse0> Need codec_data for raw AAC 0:00:00.651291416 65255 0x600001b395c0 ERROR aacparse gstaacparse.c:355:gst_aac_parse_sink_setcaps:<aacparse0> Need codec_data for raw AAC 0:00:00.653903500 65255 0x600001b395c0 ERROR WINE unixlib.c:227:link_element_to_sink: Failed to find src pad compatible to <'':sink> on <audioresample1>. 0:00:00.654040541 65255 0x600001b395c0 ERROR WINE wg_transform.c:788:wg_transform_create: Failed to create winegstreamer transform. ``` Full logs added with GST_DEBUG=3 and logging channel mfplat. -- 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