[Bug 49939] New: Clive Barker's Jericho Demo claims not enough room on C: (NtMapViewOfSection returns STATUS_NOMEMORY)
https://bugs.winehq.org/show_bug.cgi?id=49939 Bug ID: 49939 Summary: Clive Barker's Jericho Demo claims not enough room on C: (NtMapViewOfSection returns STATUS_NOMEMORY) Product: Wine Version: 5.18 Hardware: x86-64 URL: https://www.gamepressure.com/download.asp?ID=17454 OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gijsvrm(a)gmail.com Blocks: 34747 Distribution: ArchLinux Created attachment 68320 --> https://bugs.winehq.org/attachment.cgi?id=68320 logs I wanted to retest bug 34747, but the demo won't install. The last test in that bug is from the 1.9 era and seems to imply that the demo used to install. I also checked on Windows 10 and it installs fine there. For multiple reasons bisecting this might be challenging. Attached is an archive containing +relay,+virtual logs from both vanilla wine and wine-staging (The ForceBottomUpAlloc patchset changes/adds tracing). I tried in both a 64bit and 32bit prefix, same result. Logs are from a 32bit prefix. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #1 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Installed successfully for me. b7a609bf0f55356722816a380d439802e9e4b534 CliveBarkersJericho_Demo.exe wine-5.18-161-gcce4f36e21 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #2 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- (In reply to Andrey Gusev from comment #1)
Installed successfully for me.
b7a609bf0f55356722816a380d439802e9e4b534 CliveBarkersJericho_Demo.exe
wine-5.18-161-gcce4f36e21
Tried again to make sure, still fails. I have this on both macOS (10.14) and Linux (ArchLinux). Same demo file (SHA1 matches) and same wine version. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Clive Barker's Jericho Demo |Clive Barker's Jericho Demo |claims not enough room on |claims not enough room on |C: (NtMapViewOfSection |C: when Wine is built with |returns STATUS_NOMEMORY) |mingw (NtMapViewOfSection | |returns STATUS_NOMEMORY) --- Comment #3 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- (In reply to Gijs Vermeulen from comment #2)
(In reply to Andrey Gusev from comment #1)
Installed successfully for me.
b7a609bf0f55356722816a380d439802e9e4b534 CliveBarkersJericho_Demo.exe
wine-5.18-161-gcce4f36e21
Tried again to make sure, still fails. I have this on both macOS (10.14) and Linux (ArchLinux). Same demo file (SHA1 matches) and same wine version.
Heh, I built the exact same wine version without mingw and now I don't experience this issue. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #4 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Still present with wine-6.0-rc5. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net URL|https://www.gamepressure.co |https://web.archive.org/web |m/download.asp?ID=17454 |/20210107195053/http://dl.4 | |players.de/f1/pc/sonstiges/ | |clivebarkers_jericho_demo.e | |xe --- Comment #5 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, stable snapshot via Internet Archive: https://web.archive.org/web/20210107195053/http://dl.4players.de/f1/pc/sonst... I can't reproduce this, it installs and run fine. When exactly is this supposed to crash? $ sha1sum clivebarkers_jericho_demo.exe b7a609bf0f55356722816a380d439802e9e4b534 clivebarkers_jericho_demo.exe $ du -sh clivebarkers_jericho_demo.exe 1.1G clivebarkers_jericho_demo.exe $ wine --version wine-6.0-rc5-19-g4ac05afd39a Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #6 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- (In reply to Anastasius Focht from comment #5)
I can't reproduce this, it installs and run fine. When exactly is this supposed to crash?
It doesn't crash, but for me the installer claims there isn't enough room on drive C: (which there definitely is). I'll attach a screenshot. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #7 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Created attachment 69094 --> https://bugs.winehq.org/attachment.cgi?id=69094 screenshot -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #8 from Anastasius Focht <focht(a)gmx.net> --- Hello Gijs, your trace: --- snip --- ... 0024:Call KERNEL32.CreateFileA(0031ebcc "C:\\users\\gverm\\Temp\\pft9080.tmp\\pftw1.pkg",80000000,00000001,00000000,00000003,00000080,00000000) ret=00401026 ... 0024:Ret KERNEL32.CreateFileA() retval=00000088 ret=00401026 0024:Call KERNEL32.CreateFileMappingA(00000088,00000000,00000002,00000000,00000000,00000000) ret=00401048 0024:Call ntdll.NtCreateSection(0031e7f4,000f0005,0031e808,0031e7f8,00000002,08000000,00000088) ret=7b06a1d9 0024:Ret ntdll.NtCreateSection() retval=00000000 ret=7b06a1d9 0024:Call ntdll.RtlNtStatusToDosError(00000000) ret=7b06a291 0024:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=7b06a291 0024:Ret KERNEL32.CreateFileMappingA() retval=0000008c ret=00401048 0024:Call KERNEL32.MapViewOfFile(0000008c,00000004,00000000,00000000,00000000) ret=0040105c 0024:Call ntdll.NtMapViewOfSection(0000008c,ffffffff,0031e824,00000000,00000000,0031e7f8,0031e820,00000001,00000000,00000002) ret=7b0384c7 0024:trace:virtual:NtMapViewOfSection handle=0x8c process=0xffffffff addr=(nil) off=000000000 size=0 access=2 0024:Ret ntdll.NtMapViewOfSection() retval=c0000017 ret=7b0384c7 0024:Call ntdll.RtlNtStatusToDosError(c0000017) ret=7b038509 0024:Ret ntdll.RtlNtStatusToDosError() retval=00000008 ret=7b038509 0024:Ret KERNEL32.MapViewOfFile() retval=00000000 ret=0040105c --- snip --- My trace: --- snip --- 0024:Call KERNEL32.CreateFileA(0031ed0c "C:\\users\\focht\\Temp\\pfte772.tmp\\pftw1.pkg",80000000,00000001,00000000,00000003,00000080,00000000) ret=00401026 ... 0024:Ret KERNEL32.CreateFileA() retval=00000088 ret=00401026 0024:Call KERNEL32.CreateFileMappingA(00000088,00000000,00000002,00000000,00000000,00000000) ret=00401048 0024:Call ntdll.NtCreateSection(0031e710,000f0005,0031e714,0031e700,00000002,08000000,00000088) ret=7b049fb4 0024: create_mapping( access=000f0005, flags=08000000, file_access=00000001, size=00000000, file_handle=0088, objattr={rootdir=0000,attributes=00000080,sd={},name=L""} ) 0024: create_mapping() = 0 { handle=008c } 0024:Ret ntdll.NtCreateSection() retval=00000000 ret=7b049fb4 0024:Call ntdll.RtlNtStatusToDosError(00000000) ret=7b049fd0 0024:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=7b049fd0 0024:Ret KERNEL32.CreateFileMappingA() retval=0000008c ret=00401048 0024:Call KERNEL32.MapViewOfFile(0000008c,00000004,00000000,00000000,00000000) ret=0040105c 0024:Call ntdll.NtMapViewOfSection(0000008c,ffffffff,0031e960,00000000,00000000,0031e968,0031e964,00000001,00000000,00000002) ret=7b0293f3 0024:trace:virtual:NtMapViewOfSection handle=0x8c process=0xffffffff addr=(nil) off=000000000 size=0 access=2 0024: get_mapping_info( handle=008c, access=00000004 ) 0024: get_mapping_info() = 0 { size=438dd5ae, flags=00800000, shared_file=0000, image={} } 0024: get_handle_fd( handle=008c ) 0024: *fd* 008c -> 47 0024: get_handle_fd() = 0 { type=1, cacheable=1, access=000f0005, options=00000020 } 0024:trace:virtual:map_view got mem with anon mmap 0x37312000-0x7abf0000 0024:trace:virtual:create_view forcing exec permission on 0x37320000-0x7abfdfff 0024:trace:virtual:virtual_map_section handle=0x8c size=438de000 offset=000000000 0024:trace:virtual:map_file_into_view forcing exec permission on mapping 0x37320000-0x7abfdfff 0024: map_view( mapping=008c, access=00000004, base=37320000, size=438de000, start=00000000 ) 0024: map_view() = 0 0024:trace:virtual:dump_view View: 0x37320000 - 0x7abfdfff (file) 0024:trace:virtual:dump_view 0x37320000 - 0x7abfdfff c-r-- 0024:Ret ntdll.NtMapViewOfSection() retval=00000000 ret=7b0293f3 0024:Ret KERNEL32.MapViewOfFile() retval=37320000 ret=0040105c 0024:Call KERNEL32.UnmapViewOfFile(37320000) ret=004010a4 ... 0024:Call ntdll.NtUnmapViewOfSection(ffffffff,37320000) ret=7b0295cf 0024: unmap_view( base=37320000 ) 0024: unmap_view() = 0 0024:Ret ntdll.NtUnmapViewOfSection() retval=00000000 ret=7b0295cf 0024:Ret KERNEL32.UnmapViewOfFile() retval=00000001 ret=004010a4 0024:Call KERNEL32.CloseHandle(0000008c) ret=004010b2 ... 0024:Ret KERNEL32.CloseHandle() retval=00000001 ret=004010bc --- snip --- Can you attach +ntdll,+virtual,+server trace? Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #9 from Anastasius Focht <focht(a)gmx.net> --- Hello Gijs, could you also do a '/proc/<pid-of-setup-process>/maps' dump at the time the message box is shown? There is probably too much fragmentation to fit a 1 GB contiguous mapping. Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #10 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Created attachment 69097 --> https://bugs.winehq.org/attachment.cgi?id=69097 +ntdll,+virtual,+server and /proc/<pid>/maps dump Attached is the requested log + dump. This was taken on my ArchLinux machine, where I can also still reproduce the issue. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #11 from Anastasius Focht <focht(a)gmx.net> --- Hello Gijs, from your logs: --- snip --- ... 0024: create_file( access=80100080, sharing=00000001, create=1, options=00000060, attrs=00000080, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/home/gverm/.wine/dosdevices/c:/users/gverm/Temp/pftd90e.tmp/pftw1.pkg" ) 0024: create_file() = 0 { handle=0088 } 0024: create_mapping( access=000f0005, flags=08000000, file_access=00000001, size=00000000, file_handle=0088, objattr={rootdir=0000,attributes=00000080,sd={},name=L""} ) 0024: create_mapping() = 0 { handle=008c } 0024:trace:virtual:NtMapViewOfSection handle=0x8c process=0xffffffff addr=(nil) off=000000000 size=0 access=2 0024: get_mapping_info( handle=008c, access=00000004 ) 0024: get_mapping_info() = 0 { size=438dd5ae, flags=00800000, shared_file=0000, image={} } 0024: get_handle_fd( handle=008c ) 0024: *fd* 008c -> 84 0024: get_handle_fd() = 0 { type=1, cacheable=1, access=000f0005, options=00000020 } 0024: close_handle( handle=008c ) 0024: close_handle() = 0 0024: close_handle( handle=0088 ) 0024: close_handle() = 0 ... --- snip --- At least the requesting mapping size is the same as mine. It probably fails in 'map_view'.
From your process address space dump it seems a lot of Wine dlls that are supposed to be PE dlls when building with MinGW are in fact not PE dlls. For example 'ucrtbase.dll' is mapped at 0x70b40000 and the sections mappings show it's certainly not a PE. Only 'lz32.dll' and maybe a few more seem to be a PE dlls.
You could run the following command sequence on your WINEPREFIX to do a quick check (your might omit 'sort' in the pipe or modify grep for only checking specific binaries/paths): --- snip --- $ grep -ralZP "Wine .* DLL" .wine/drive_c | xargs -r0i bash -c \ "if grep -obUa \"Wine builtin DLL\" \"{}\" 2>/dev/null | grep -q \"64:Wine builtin DLL\" ; \ then echo \"{}\" = PE ; else echo \"{}\" = fake ; fi" | sort .wine/drive_c/Program Files/Common Files/System/ADO/msado15.dll = PE .wine/drive_c/Program Files/Common Files/System/OLE DB/msdaps.dll = PE .wine/drive_c/Program Files/Common Files/System/OLE DB/oledb32.dll = PE .wine/drive_c/Program Files/Internet Explorer/iexplore.exe = PE .wine/drive_c/Program Files/Windows Media Player/wmplayer.exe = PE .wine/drive_c/Program Files/Windows NT/Accessories/wordpad.exe = PE .wine/drive_c/Program Files (x86)/Common Files/System/ADO/msado15.dll = PE .wine/drive_c/Program Files (x86)/Common Files/System/OLE DB/msdaps.dll = PE .wine/drive_c/Program Files (x86)/Common Files/System/OLE DB/oledb32.dll = PE .wine/drive_c/Program Files (x86)/Internet Explorer/iexplore.exe = PE .wine/drive_c/Program Files (x86)/Windows Media Player/wmplayer.exe = PE .wine/drive_c/Program Files (x86)/Windows NT/Accessories/wordpad.exe = PE .wine/drive_c/windows/command/start.exe = PE .wine/drive_c/windows/explorer.exe = PE .wine/drive_c/windows/hh.exe = PE ... .wine/drive_c/windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.6000.16386_none_deadbeef/gdiplus.dll = PE .wine/drive_c/windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23038_none_deadbeef/gdiplus.dll = PE .wine/drive_c/windows/winsxs/x86_microsoft-windows-msxml30_31bf3856ad364e35_6.0.6000.16386_none_deadbeef/msxml3.dll = fake .wine/drive_c/windows/winsxs/x86_microsoft-windows-msxml60_31bf3856ad364e35_6.0.6000.16386_none_deadbeef/msxml6.dll = PE --- snip --- It's from my gists: https://gist.github.com/rmi1974/f554b00609cdb0cdc32724d47a163fd2 (not 100% complete though) Which exact MinGW version/package are you using? Distro or Martin's (https://github.com/mstorsjo/llvm-mingw)? Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #12 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Created attachment 69099 --> https://bugs.winehq.org/attachment.cgi?id=69099 dump --- snip --- You could run the following command sequence on your WINEPREFIX to do a quick check --- snip --- Attached is the output of that command, which shows that most are PE, including ucrtbase.dll. --- snip --- Which exact MinGW version/package are you using? Distro or Martin's (https://github.com/mstorsjo/llvm-mingw)? --- snip --- My distro packages. <https://archlinux.org/packages/community/x86_64/mingw-w64-gcc/> -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49939 --- Comment #13 from Anastasius Focht <focht(a)gmx.net> --- Hello Gijs, took a bit but then I remembered bug 48417, specifically https://bugs.winehq.org/show_bug.cgi?id=48417#c4 The default image base for Wine 32-bit PE builtins is 0x10000000 when built with LLVM based MinGW which causes relocation into low address space range for almost every PE dll in my case. The exception are Wine core dlls with hard-coded image base and hybrids that have not been converted to PE format. Your distro MinGW uses '--enable-auto-image-base' by default which hard-codes a unique image base for every PE builtin. The few PE builins that are mapped to low address range in your case are just relocated due to address space collisions when the linker calculated an image base that overlaps into an existing one. FYI 32-bit installer isn't linked with '/LARGEADDRESSAWARE'. In your case, the remaining big "hole" is simply not large enough for mapping size of 0x438e0000 (1081 MiB): --- snip --- ... 007c0000-00af4000 r-xs 00000000 08:12 30802136 .. wine/nls/sortdefault.nls ... 00f51000-20000000 ---p 00000000 00:00 0 61740000-61766000 r-xp 00000000 08:12 36179889 32Bit/dlls/advapi32/advapi32.dll ... --- snip --- My case, with most PE builtins mapped to low range gives better layout because 0x6XXXXXXX range is not consumed. --- snip --- ... 100de000-101da000 r-xp 000be000 fd:01 17601058 x86_64/lib/wine/user32.dll 101da000-20000000 ---p 00000000 00:00 0 ... 7ac46000-7ac49000 rwxp 00046000 fd:01 17600982 ... x86_64/lib/wine/riched20.dll --- snip --- You could try to pass '--disable-auto-image-base' to your Distro MinGW to achieve a better address space layout. Downside: small performance penalty on the loader side due to more dll relocations. Regards -- 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.
participants (1)
-
WineHQ Bugzilla