[Bug 56371] New: WinUAE 5.2.0 running under Wine 9 under Fedora 39
https://bugs.winehq.org/show_bug.cgi?id=56371 Bug ID: 56371 Summary: WinUAE 5.2.0 running under Wine 9 under Fedora 39 Product: Wine-staging Version: 9.0 Hardware: x86-64 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gilles.pelletier(a)live.fr CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Fedora 39 wine-9.0 (Staging) WinUAE64.exe 5.2.0 (but also true with 5.0.0 and 4.4.0) When using the JIT feature of WinUAE, like 68020 JIT, we encounter the following error: JIT: Serious Error: JIT: 64-bit pointer (0x101080000) at C:\projects\winuae\src\jit\compemu_support.cpp:2579 (fatal) If I untick JIT, it starts and run well. What's wrong ? This issue exists since the Wine 8.xx version: Fedora 38 / Wine 8.14-stable / WinUAE 5.0.0 64 bits When using 68020+ and JIT, WinUAE crashes at start. The workaround is to disable JIT. Many thanks to fix this. -- 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=56371 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #1 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Created attachment 76443 --> https://bugs.winehq.org/attachment.cgi?id=76443 debug-workaround.diff I received this message also with vanilla wine 9.8. And I think I could follow it back to winuae trying to allocate 0xa0100000 bytes at address 0x80000000. As the end of this allocation exceeds the 32-bit addressable area, winuae tries another allocation without requesting a start address [1]. This second allocation returns an address also starting above the 32-bit boundary, and therefore triggers the visible message "JIT: 64-bit pointer". This problematic size of 0xa0100000 seems to be calculated from the returned values of calls to GlobalMemoryStatus / GlobalMemoryStatusEx [3]. By returning in wine from GlobalMemoryStatusEx some smaller values than the real ones (attached diff), I got winuae to just reserve 0x10100000 bytes at address 0x80000000, which seems to work and produces no more error message. Therefore it looks like this is related to the values returned by GlobalMemoryStatus(Ex). [1] https://github.com/tonioni/WinUAE/blob/5200/vm.cpp#L308-L311 [2] https://github.com/tonioni/WinUAE/blob/5200/jit/compemu.h#L576-L577 [3] https://github.com/tonioni/WinUAE/blob/5200/od-win32/mman.cpp#L161-L215 -- 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=56371 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Product|Wine-staging |Wine Component|-unknown |-unknown URL| |https://download.abime.net/ | |winuae/releases/InstallWinU | |AE5200.msi CC|leslie_alistair(a)hotmail.com | |, z.figura12(a)gmail.com | -- 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=56371 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source -- 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=56371 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|WinUAE 5.2.0 running under |WinUAE: JIT error |Wine 9 under Fedora 39 | -- 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=56371 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://download.abime.net/ |https://download.abime.net/ |winuae/releases/InstallWinU |winuae/releases/InstallWinU |AE5200.msi |AE5200_x64.msi -- 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=56371 Andrew Nguyen <arethusa26(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Nguyen <arethusa26(a)gmail.com> --- While the workaround of limiting the reported values from GlobalMemoryStatusEx is effective, I think it's not the underlying cause of the issue. On Windows 10, the WinUAE logger shows the following output for the MMAN allocation across repeated runs: MMAN: Total physical RAM 32658 MB, all RAM 78827 MB MMAN: Attempting to reserve: 2561 MB VM: Reserve 0xa0100000 bytes, try address 0x80000000 VM: Reserve 0xa0100000 bytes, got address 0x80000000 (> 32-bit) VM: Reserve 0xa0100000 bytes failed! MMAN: Reserved 000000007FFF0000-00000001200F0000 (0xa0100000 2561M) Wine shows similar output except that the base address of the reservation (which varies across runs) is outside of the 32-bit address space: MMAN: Total physical RAM 15868 MB, all RAM 34890 MB MMAN: Attempting to reserve: 2561 MB VM: Reserve 0xa0100000 bytes, try address 0x80000000 VM: Reserve 0xa0100000 bytes, got address 0x80000000 (> 32-bit) VM: Reserve 0xa0100000 bytes failed! MMAN: Reserved 00007FF2DD800000-00007FF37D900000 (0xa0100000 2561M) Somehow, on Windows, the final call to VirtualAlloc, which does not specify a start address, always results in a base address that fits in a 32-bit pointer. -- 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=56371 --- Comment #3 from Andrew Nguyen <arethusa26(a)gmail.com> --- Created attachment 76445 --> https://bugs.winehq.org/attachment.cgi?id=76445 WINEDEBUG=+relay,+seh,+tid,+virtual trace -- 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=56371 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- OS|other |Linux --- Comment #4 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- The 32-bit version of WinUAE works correctly? -- 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=56371 --- Comment #5 from Andrew Nguyen <arethusa26(a)gmail.com> --- (In reply to Ken Sharp from comment #4)
The 32-bit version of WinUAE works correctly?
The JIT "serious error" assertion failure never appears on 32-bit WinUAE. It's specific to 64-bit WinUAE as it's not possible or sensible for VirtualAlloc to return a 64-bit pointer in a 32-bit process. -- 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=56371 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |win64 -- 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=56371 --- Comment #6 from Andrew Nguyen <arethusa26(a)gmail.com> --- Created attachment 76488 --> https://bugs.winehq.org/attachment.cgi?id=76488 C source for VirtualAlloc test program I believe I've identified why the WinUAE MMAN allocation on Windows has a low base address. Running winedump on winuae64.exe shows the following flags set for the PE file header characteristics field: Characteristics: 0023 RELOCS_STRIPPED EXECUTABLE_IMAGE LARGE_ADDRESS_AWARE It also sets the following flags for the DLL characteristics field in the PE optional header: DLL characteristics: 0x8120 HIGH_ENTROPY_VA NX_COMPAT TERMINAL_SERVER_AWARE MSDN documents the IMAGE_FILE_RELOCS_STRIPPED flag as indicating that "the file does not contain base relocations and must therefore be loaded at its preferred base address." However, this flag being set along with IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA, which allows for 64-bit ASLR, seems contradictory. Attached is a test program that calls VirtualAlloc with a large size and no preferred address for a MEM_RESERVE request, in the same fashion as WinUAE, and reports the returned address. I compiled the program twice with x86_64-w64-mingw32-gcc, with one built with no special flags and another with -Wl,--disable-reloc-section. I observed the following results on Windows 10: C:\Users\Public>large_virtualalloc.exe VirtualAlloc returned 0000028b56e10000 C:\Users\Public>large_virtualalloc_reloc_stripped.exe VirtualAlloc returned 000000007fff0000 The mingw ld refuses to allow the IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA or IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flags to be set without enabling relocations, so I copied the reloc-stripped executable and modified the copy directly to set a combination of the two flags. I observed the following results: C:\Users\Public>large_virtualalloc_reloc_stripped_dynbase.exe VirtualAlloc returned 000000007fff0000 C:\Users\Public>large_virtualalloc_reloc_stripped_high_va.exe VirtualAlloc returned 000000007fff0000 C:\Users\Public>large_virtualalloc_reloc_stripped_dynbase_high_va.exe VirtualAlloc returned 000000007fff0000 For completeness, I also built an executable with relocations available but ASLR completely disabled (no HIGH_ENTROPY_VA or DYNAMIC_BASE flags) and tested it: C:\Users\Public>large_virtualalloc_reloc_no_aslr.exe VirtualAlloc returned 000000007fff0000 All these test cases on wine-9.9 show VirtualAlloc returning a high address outside a 32-bit address space. I deduce that, on Windows, disabling ASLR for an executable results in VirtualAlloc preferring lower addresses first if no preferred address is explicitly requested. -- 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