Date: Wed, 23 Mar 2022 17:26:52 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262378 --- Comment #10 from Damjan Jovanovic <firstname.lastname@example.org> --- 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.