New subject: [Bug 60445] win32u: vkFreeMemory leaks the host-pointer block of host-visible allocations in WoW64 processes

Oct. 6, 2026

      http://bugs.winehq.org/show_bug.cgi?id=60445

            Bug ID: 60445
           Summary: win32u: vkFreeMemory leaks the host-pointer block of
                    host-visible allocations in WoW64 processes
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: win32u
          Assignee: wine-bugs@list.winehq.org
          Reporter: wildart@gmail.com
  Target Milestone: ---
      Distribution: ---

Created attachment 82258
  --> http://bugs.winehq.org/attachment.cgi?id=82258
MWE error source

Component: vulkan · Version: 11.0 · Keywords: regression, testcase

Description

In a 32-bit process under the new WoW64 mode, every vkAllocateMemory on a
host-visible memory type reserves a NtAllocateVirtualMemory block for
VK_EXT_external_memory_host import. vkFreeMemory never releases that block.An
application that allocates and frees host-visible memory repeatedly, for
example a staging buffer per upload, exhausts its 2 GiB address space even
though it frees every allocation.

This path is taken when the host driver exposes VK_EXT_external_memory_host but
Wine doesn't use placed mapping (map_placed_align == 0). MoltenVK on macOS is
one such driver.

Steps to reproduce

1. i686-w64-mingw32-gcc -O2 -I<vulkan-headers>/include vk_hostmem_leak.c -o
vk_hostmem_leak.exe (source attached)
2. wine vk_hostmem_leak.exe

The test allocates a 16 MiB host-visible VkDeviceMemory and frees it, 1000
times. At most one allocation is live at any moment.

Actual result

  wine 11.0
  device Apple M5 Pro, driver 0x28a1
  memory type 1, allocating and freeing 16 MiB x 1000
  FAIL: vkAllocateMemory returned -1 at iteration 125 (2000 MiB allocated and
freed); VirtualAlloc(16 MiB) also fails: address space exhausted

Expected result

  PASS: 1000 allocations of 16 MiB

Analysis (dlls/win32u/vulkan.c, current master)

  - allocate_external_host_memory() stores the NtAllocateVirtualMemory result
only in its local mapping and passes it on through import_info->pHostPointer.
It never returns the pointer to the caller.
  - win32u_vkAllocateMemory() has its own local void *mapping = NULL, which is
never assigned, and does memory->vm_map = mapping. As a result, vm_map stays
NULL.
  - win32u_vkFreeMemory() releases the block only if (memory->vm_map), so it
never does.
  - allocate_external_host_memory() also leaks the block on its own error
paths: when vkGetMemoryHostPointerPropertiesEXT fails, and on the failed: path
in win32u_vkAllocateMemory.

This is a regression. In Wine 10.0, wine_vkAllocateMemory() in
dlls/winevulkan/vulkan.c assigns the block to memory->vm_map, and
wine_vkFreeMemory() releases it. The leak appears to date from the move of this
code to win32u. I haven't bisected the exact commit.

Suggested fix

Have allocate_external_host_memory() return the block, for example through an
out parameter. Store it in memory->vm_map, and release it on the error paths.
The existing vm_map handling in win32u_vkFreeMemory() and
win32u_vkUnmapMemory2KHR() should then work as intended.

Environment

  macOS 26.6, Apple M5 Pro, MoltenVK 1.4.1, Wine 11.0 (new WoW64)

-- 
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.

[Bug 60445] New: win32u: vkFreeMemory leaks the host-pointer block of host-visible allocations in WoW64 processes

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)