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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262378

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

c0000017 == STATUS_NO_MEMORY

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

---snip---
    /* reserve space for shared user data */
    status = NtAllocateVirtualMemory( NtCurrentProcess(),
        (void **)&user_shared_data, 0, &data_size,
        MEM_RESERVE | MEM_COMMIT, PAGE_READONLY );
---snip---

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
to:

mmap((void *)0x7ffe0000, 4096, PROT_READ,
     MAP_PRIVATE|MAP_FIXED|MAP_ANON|MAP_EXCL, -1, 0);

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.