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

[Bug 52621] New: Failed test of `alternate_success_code` from `windows-rs`
by WineHQ Bugzilla Sept. 18, 2026

Sept. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=52621 Bug ID: 52621 Summary: Failed test of `alternate_success_code` from `windows-rs` Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal(a)protonmail.com Distribution: --- This test pass on Windows 10 Failures ``` running 1 test test test ... FAILED failures: ---- test stdout ---- thread 'test' panicked at 'assertion failed: hr == CO_E_NOTINITIALIZED', crates\tests\alternate_success_c ode\tests\test.rs:9:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: test ``` Rust for Windows can be installed via https://forge.rust-lang.org/infra/other-installation-methods.html or directly https://static.rust-lang.org/dist/rust-1.59.0-x86_64-pc-windows-gnu.msi Steps to reproduce git clone https://github.com/microsoft/windows-rs.git cd windows-rs git checkout 9965e3c44829d0c86b2d9d2b3c5338376f158bde cd crates/tests/alternate_success_code/ wine cargo test -- 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 2

[Bug 52620] New: Failed test of `win32_arrays` from `windows-rs`
by WineHQ Bugzilla Sept. 18, 2026

Sept. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=52620 Bug ID: 52620 Summary: Failed test of `win32_arrays` from `windows-rs` Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal(a)protonmail.com Distribution: --- This test pass on Windows 10 Failures ``` failures: ---- keyboard_state stdout ---- thread 'keyboard_state' panicked at 'assertion failed: state != zeroed', crates\tests\win32_arrays\tests\ fixed.rs:9:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ---- temp_file stdout ---- thread 'temp_file' panicked at 'assertion failed: `(left == right)` left: `[46, 92, 116, 101, 115, 55, 98, 46, 116, 109, 112, 0]`, right: `[46, 92, 116, 101, 115, 55, 66, 46, 116, 109, 112, 0]`', crates\tests\win32_arrays\tests\fixed.r s:20:9 failures: keyboard_state temp_file ``` Rust for Windows can be installed via https://forge.rust-lang.org/infra/other-installation-methods.html or directly https://static.rust-lang.org/dist/rust-1.59.0-x86_64-pc-windows-gnu.msi Steps to reproduce git clone https://github.com/microsoft/windows-rs.git cd windows-rs cd crates/tests/win32_arrays/ wine cargo test -- 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 2

[Bug 59857] New: ntdll: process heap grows without bound under sustained allocation load; subheaps are never returned to the OS
by WineHQ Bugzilla Sept. 18, 2026

Sept. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59857 Bug ID: 59857 Summary: ntdll: process heap grows without bound under sustained allocation load; subheaps are never returned to the OS Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: nen24t(a)gmail.com Distribution: --- ## Summary A process running an application that issues a high, sustained rate of small/medium heap allocations with mixed lifetimes (e.g. a Direct2D GUI redrawing continuously) shows **unbounded RSS growth that never plateaus and is never returned to the OS**, even though the live working set is stable. Growth stops the instant the redraw load stops, but RSS does not shrink. Observed up to **3.9 GB RSS without crashing**. The growth is **fully attributable to the ntdll heap's `allocate_region()` path** creating subheaps and large blocks that are never decommitted. ## Reproduction - **Wine**: 11.0 (stable), unmodified / vanilla build. Reproduces equally without any third-party D3D layer (builtin wined3d/d3d11/d2d1, OpenGL backend). - **Also reproduces on 11.10 (devel)**: the same unbounded growth is observed. Note that `dlls/ntdll/heap.c` is **functionally identical between 11.0 and 11.10** — the only diff is the removal of one unrelated `#define WIN32_NO_STATUS`; `allocate_region()`, `create_subheap()`, `subheap_decommit()` and the subheap/LFH logic are byte-for-byte unchanged. The mechanism is therefore the same across both releases. - **Workload**: A DAW (REAPER) hosting a Direct2D-based VST plugin GUI (Serum 2) with a continuously animating waveform display (steady ~tens-of-thousands of D2D draw calls per second). Any application doing continuous `ID2D1RenderTarget` drawing with per-frame transient geometry should reproduce; the plugin is just a convenient high-rate driver. - **Observe**: `ps -o rss= -p <pid>` (or `/proc/<pid>/status` `VmRSS`) over a few minutes of active GUI. RSS climbs at a roughly constant rate and does not recover. ## Observed behaviour (measured) - RSS growth rate under active load: **~1.2–1.6 MB/s**, linear, unbounded. - Growth is **100% in anonymous mappings**. Categorising `/proc/<pid>/smaps` over a 2-minute window: `ANON` grows +~190 MB while **every other category is flat** — NVIDIA GL driver mappings flat (~340 MB), glibc `[heap]` flat (~12 MB), file-backed/PE/SO flat. - Per-VMA diff shows the growth concentrated in a **small number of large, growing anonymous regions** (e.g. one region growing to >120 MB), **not** VMA churn (the mapping count is stable). This is the signature of one or a few heaps/arenas committing incrementally. ## Analysis — attribution to the ntdll heap Layered attribution (each step ruled out a candidate): 1. **Not the LFH frontend.** Walking all LFH groups and classifying by live-block count: committed LFH memory **plateaus** (empty-group caching is bounded by the per-bin group cache). Sparse LFH groups dominate over empty ones (~1:9–11 by wasted bytes), but the LFH total does not grow unbounded. LFH-level decommit/pruning has no effect (consistent with the heap immediately reusing freed interior blocks). 2. **Not Win32 `VirtualAlloc`.** Sampling all `VirtualAllocEx`/`MEM_COMMIT` calls: effectively zero committed bytes via this path even at multi-GB RSS. The large allocations bypass it. 3. **Heap-committed breakdown.** Summing committed bytes per heap (all subheaps + large blocks): the **process heap reaches ~770 MiB** (≈597 MiB across ~42 subheaps, max 15 MiB each, plus ~172 MiB across ~66 large blocks) and keeps growing. All other ntdll heaps stay < 4 MiB. 4. **Direct `NtAllocateVirtualMemory` caller.** Attributing each large committed `NtAllocateVirtualMemory` call to its PE return address (read from the syscall frame, resolved offline via `/proc/<pid>/maps` + `nm`/`addr2line`): the dominant driver is **`allocate_region()` in `dlls/ntdll/heap.c`** — ~201 MiB across ~87 calls in a 2-minute window. `allocate_region()` is called from `create_subheap()` and `heap_allocate_large()`. ## Root cause (as understood) The growth is **process-heap fragmentation that is never returned to the OS**, in the **non-LFH range** (mid-size blocks → subheaps) and large blocks: - A subheap holds blocks of mixed size-classes and mixed lifetimes. `subheap_decommit()` only releases trailing free space at the end of a subheap; a subheap that retains even a single long-lived ("residue") block stays fully committed. - Under a workload that allocates many short-lived blocks per frame plus occasional long-lived ones (geometry/shader/glyph objects), subheaps accumulate in a sparse state: low live occupancy, but pinned by residue blocks and therefore never freed. The result is monotonic committed growth with a stable live set. The allocations filling the heap (from caller sampling) are ordinary builtin-DLL allocations: wined3d shader objects (`pixel_shader_init`/`shader_set_function`, ~17–23 KB), d2d1 transient geometry, dwrite glyph/layout structs, d3d11 — nothing unusual; the issue is the heap's retention behaviour, not the callers. This is not D2D1-specific in principle — D2D1/wined3d is just an intense, mixed-lifetime driver that exposes it quickly. ## Context: Windows behaviour On Windows 10+, the Segment Heap (used by default for many processes, and selectable via `HEAP_CREATE_SEGMENT_HEAP` / image-file-execution-options `FrontEndHeapType`) groups allocations into size-class-homogeneous segments and returns empty segments to the OS, so this mixed-lifetime workload does not accumulate the same way. Wine's heap is the classic NT heap (no Segment Heap; `HEAP_CREATE_SEGMENT_HEAP` is not implemented), which never returns interior subheap pages once a subheap is pinned. This is noted only as behavioural context — not as a fix proposal. ## How the data was gathered (for independent reproduction) All instrumentation was diagnostic-only (counters + periodic `ERR()` dumps), removed afterwards: - VMA categorisation and per-VMA growth diff from `/proc/<pid>/smaps`. - Per-heap committed totals (sum over `subheap_list` of `commit_end - base`, plus `large_list`). - `NtAllocateVirtualMemory` caller attribution: aggregate committed bytes by the PE return IP taken from the syscall frame (`rsp`-saved return address, not the syscall stub IP), resolved against the loaded PE modules. Raw per-window measurement tables can be attached on request. ## Related bugs - **Bug 55818** — earlier report of related Direct2D-driven RSS growth. This report adds precise attribution (driven by `allocate_region()` / subheap retention in the *process heap*, not the LFH) plus a vanilla and cross-version confirmation (heap code identical 11.0 ↔ 11.10). - **Bug 57289** — concerns the LFH frontend (`group_release`). The data here indicates the **LFH is NOT the source** of the unbounded growth: LFH committed memory plateaus; the accumulation is one level up, in non-LFH subheaps and large blocks that `allocate_region()` creates and never decommits. Cross-referenced to help refocus the investigation. (Adjust/verify the bug numbers and titles before submitting; also add them to the "See Also" field of the new bug.) ## Severity / impact Long-running sessions of Direct2D-heavy applications (DAWs with plugin GUIs, etc.) hit out-of-memory after a few hours despite a small, stable live working set. Closing the GUI stops growth but does not reclaim; only process exit (which `HeapDestroy`s everything at once) recovers the memory. -- 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 25

[Bug 53795] New: Emojis crash Naver LINE (and possibly all Qt applications)
by WineHQ Bugzilla Sept. 18, 2026

Sept. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=53795 Bug ID: 53795 Summary: Emojis crash Naver LINE (and possibly all Qt applications) Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: pq2sx44teeigl7za(a)chyen.cc Distribution: --- Created attachment 73289 --> https://bugs.winehq.org/attachment.cgi?id=73289 Source of a trivial Qt application to reproduce the issue Naver LINE (installer at [1]) crashes if I paste some kinds of emojis, like ???? (U+1F972) or ???? (U+1F970). Crashes happen with all kinds of text boxes, including username in the login dialog, search box and messaging dialog. Crash does not happen if I uninstalled the Noto Color Emoji font [2]. Without WINEDEBUG, crashes are intermittent. With WINEDEBUG=+font, I always get crashes. The issue can be reproduced with a trivial Qt application (source attached). The backtrace from a Qt 5.12.12 MinGW debug build [3] is also attached. >From the backtrace, Qt crashes when trying to get the string from otm->otmpFullName [4]. In a gdb session, the address (otm + otm->otmpFullName) points to an invalid address (needs to add otm per [5]). Apparently GetOutlineTextMetrics does not correctly assign that pointer. [1] https://desktop.line-scdn.net/win/new/LineInst.exe [2] https://archlinux.org/packages/extra/any/noto-fonts-emoji/ [3] https://download.qt.io/archive/qt/5.12/5.12.12/qt-opensource-windows-x86-5.… [4] https://github.com/qt/qtbase/blob/v5.12.12/src/platformsupport/fontdatabase… [5] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-outlin… -- 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 51443] New: Test fails in remove_dir_all crate when creating file
by WineHQ Bugzilla Sept. 17, 2026

Sept. 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=51443 Bug ID: 51443 Summary: Test fails in remove_dir_all crate when creating file Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal(a)protonmail.com Distribution: --- Hi, Steps to reproduce on clear wine-devel 6.12 ``` wget https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi msiexec /i rust-1.53.0-x86_64-pc-windows-gnu.msi git clone https://github.com/XAMPPRocky/remove_dir_all.git cd remove_dir_all git checkout 9b164cecdb4a0590af68be8b22f9c747402237e3 wine cargo test ``` should print this ``` running 4 tests test removes_read_only ... FAILED test removes_empty ... ok test removes_files ... ok test removes_dirs ... ok failures: ---- removes_read_only stdout ---- thread 'removes_read_only' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access denied." }', tests\windows.rs:68:49 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: removes_read_only test result: FAILED. 3 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s error: test failed, to rerun pass '--test windows' ``` I tested it and this works fine in Windows Server 2019 Source code of failed test - https://github.com/XAMPPRocky/remove_dir_all/blob/9b164cecdb4a0590af68be8b2… ``` fn removes_read_only() { env_logger::init(); for i in 0..5 { let path = format!("./readonly/{}/subdir", i); fs::create_dir_all(&path).unwrap(); let file_path = format!("{}/file.txt", path); { let file = File::create(&file_path).unwrap(); ``` -- 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 33126] New: divided SysEx and coalesced midiOutLongMsg
by wine-bugs＠winehq.org Sept. 16, 2026

Sept. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=33126 Bug #: 33126 Summary: divided SysEx and coalesced midiOutLongMsg Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Classification: Unclassified Johannes Kroll reported in wine-patches that the KORG Kontrol Editor software hung after sending an ill-formed SysEx via winealsa's midiOutLongMsg. http://www.winehq.org/pipermail/wine-patches/2013-January/121335.html The MIDIHDR data is F0 ... F7 00 00 00 (125 bytes). http://www.winehq.org/pipermail/wine-devel/2013-February/098852.html He observed that no hang occurs when skipping the trailing 3 zero bytes. F7 is the "End Of SysEx" (EOX) marker. It is still unclear what happens. MIDI HW is expected to skip over bogus bytes, thus the zero bytes should cause no harm. OTOH, ALSA might be getting into trouble processing ill-formed messages, and we don't know if or how many bytes ALSA actually sent out through the serial port. In any case, midiOutLongMsg handling in Wine needs fixes. - winealsa should extract the F0...F7 part and send that as a SysEx. - More generally, midiOutLong is known to accept not only SysEx packets, but also coalesced status messages. Some MIDI authors prefer to send e.g. chords via one LongMsg rather than successive calls to midiOutShortMsg, arguing that it's faster. Hence all Wine MIDI drivers need to decompose midiOutLongMsg into packets consisting of status message, regular SysEx ... and possibly junk. - All APIs (MS, ALSA, OSS, CA) acknowledge the existence of divided SysEx. As a result, framing SysEx with F0 ... F7 is entirely under application control. The current winealsa framing code is simply wrong. - winecoreaudio always declared 3 bytes for short messages, even program change. I have written a sequence of patches to fix all of this. The only thing that is unclear is how to encapsulate garbage data like the above 3 zero bytes or real time messages with ALSA. What ALSA API function and what ALSA message type to use? Heck, I'm not even sure winealsa.drv/midi.c:modData is ok to send a 2-byte MTC quarter frame via snd_seq_ev_set_sysex instead of using a primitive that sets the type SND_SEQ_EVENT_CLOCK/TICK. -- 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 5

[Bug 56043] New: Native Wayland Touchpad scroll doesn't work
by WineHQ Bugzilla Sept. 16, 2026

Sept. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=56043 Bug ID: 56043 Summary: Native Wayland Touchpad scroll doesn't work Product: Wine Version: 9.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: capybaraserene(a)gmail.com Distribution: --- Native Wayland is working almost perfect for several of my apps for the first time. Great job! It's almost perfect now except touchpad scrolling doesn't work. WineHQ: wine-devel64-9.0.rc2-1.1.x86_64 Fedora 39 GNOME Wayland XWayland: Touchpad scroll works =============================== * DISPLAY=:0 * wine explorer.exe * two finger scroll works Native Wayland: Touchpad scroll doesn't work ============================================ * regedit HKEY_CURRENT_USER\Software\Wine\Drivers\Graphics x11,wayland * unset DISPLAY * wine explorer.exe * two finger scroll doesn't work -- 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 55705] New: PDF Xchange editor crashes
by WineHQ Bugzilla Sept. 16, 2026

Sept. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55705 Bug ID: 55705 Summary: PDF Xchange editor crashes Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: donescamillo(a)gmail.com Distribution: --- Wine 8.17 development branch. PdfXchange Editor free version i.e. not registered version. portable, version 10.0.1.371 Linux Mint 21.2 PdfXchange editor works OK, can highlight, add labels, images, whatever the free version allows. The problem is that after some time, when PdfXchange Editor is being closed, it hangs, and the dialog asking for forcing the application to close appears. This happens in previous versions, too. -- 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 21

[Bug 46871] New: err:rpc: rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87
by wine-bugs＠winehq.org Sept. 15, 2026

Sept. 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=46871 Bug ID: 46871 Summary: err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 Product: Wine Version: 4.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)winehq.org Reporter: susancragin(a)earthlink.net Distribution: --- Created attachment 63932 --> https://bugs.winehq.org/attachment.cgi?id=63932 NaturallySpeaking 13 setup log When installing Dragon NaturallySpeaking 13, the installation hangs up right at the last instruction. A prior bug 46160 was filed about NatSpeak 13 hanging up at the end of installation, and I think that bug might have been fixed in the most recent wine version, and this other bug uncovered. bug 46160 Anyway, the installation stops as of this: err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 I have posted the installation log. If I kill the installation and then try to start the program, the program works up to a point. It waves hello, and then asks if I want to register the program immediately or run it up to 5 times without registering. When I hit either of these options, the program crashes. I have included the crash log also. -- 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 13

[Bug 60128] New: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM)
by WineHQ Bugzilla Sept. 15, 2026

Sept. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60128 Bug ID: 60128 Summary: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM) 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: empcomputer(a)outlook.com.au Target Milestone: --- Distribution: --- Created attachment 81701 --> http://bugs.winehq.org/attachment.cgi?id=81701 Notepad after launch - OK Running Linux Mint 22.3 Cinnamon. If window manager decorations are enabled and a window is resized/maximised/restored, mouse coordinates are reported incorrectly, resulting in an offset between the on-screen cursor position and hit point. Also manifests as a menu activated by keyboard accelerators appearing in incorrect position. I have found that, under certain conditions (can't see a clear pattern, but seems to depend on window position and size), the window manager triggers ConfigureNotify events for the client window before the parent (frame) window. When this happens, the X11 driver computes the window rectangles using the old frame coordinates, leading to the offset problem described earlier. If window manager decorations are disabled, the problem does not occur (there is no frame window in that case). Simple repro steps: - Ensure that "Allow the window manager to decorate the windows" and "Allow the window manager to control the windows" options are checked - Ensure that "Emulate a virtual desktop" is UNchecked - Launch Notepad - Position the window approximately in the centre of the screen (away from the top-left corner) - Maximise the window - Pull down a menu using the keyboard (e.g. Alt+F or Alt+H) - Note that the menu appears away from the expected position - If you restore the window, you'll notice a similar effect (with reversed offsets) - Moving the window using the title bar corrects the coordinates The problem was first noticed in Wine 11.13, but testing shows that it goes back as far as ~10.0. It is more pronounced/consistent in 11.13, but can be triggered sporadically in some earlier versions as well. After looking through the code and some experimenting, one possible fix is to modify the "host_window_map_point" function to use XTranslateCoordinates. I'm not sure if it's the best solution; I imagine there's a good reason it was coded the way it is (e.g. performance issues due to X protocol overhead - I haven't looked into it enough). I hope I have at least provided a good starting point. I'll also note that I have tested it with a few other window managers (Xfwm, Metacity and Compiz, running Linux Mint 22.3 Xfce Live ISO in VirtualBox) and they did not exhibit the same problem. (More attachments to follow...) -- 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 11