[Bug 262378] emulators/wine-devel won't start on CURRENT due to ASLR changes

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 23 Mar 2022 17:26:52 UTC

--- Comment #10 from Damjan Jovanovic <damjan.jov@gmail.com> ---
err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data:

c0000017 == STATUS_NO_MEMORY

virtual_alloc_first_teb() in dlls/ntdll/unix/virtual.c gives that error when
this fails:

    /* reserve space for shared user data */
    status = NtAllocateVirtualMemory( NtCurrentProcess(),
        (void **)&user_shared_data, 0, &data_size,

where, importantly:

struct _KUSER_SHARED_DATA *user_shared_data = (void *)0x7ffe0000;

That NtAllocateVirtualMemory() calls map_view() which calls map_fixed_area(),
where mmap_is_in_reserved_area() returns 0 ("not in a reserved area, do a
normal allocation"), leading to a call to anon_mmap_tryfixed(), which attempts

mmap((void *)0x7ffe0000, 4096, PROT_READ,

This fails, setting off the error message and exit.

Why does it fail? Dumping /proc/curproc/map just before or after the mmap
failure, shows this enormous mapping already occupying the required memory
range (0x7ffe0000 - 0x7ffe1000):

0x62bd6000 0x82bb6000 0 0 0 --- 0 0 0x0 NCOW NNC none - NCH -1

It's 536,739,840 bytes (or 0x1ffe0000) long!

When I make a standalone binary that calls mmap() with those arguments, it
succeeds, so that large mapping is not a standard feature of FreeBSD 14-CURRENT
with ASLR. Where did it come from?

You are receiving this mail because:
You are the assignee for the bug.