[Bug 56371] New: WinUAE 5.2.0 running under Wine 9 under Fedora 39

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
                CC: [e-mail], [e-mail]

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.

[Bug 56371] WinUAE 5.2.0 running under Wine 9 under Fedora 39

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Bernhard Übelacker  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Bernhard Übelacker  ---
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

[Bug 56371] WinUAE 5.2.0 running under Wine 9 under Fedora 39

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download
            Product|Wine-staging                |Wine
          Component|-unknown                    |-unknown
                URL|                            |https://download.abime.net/
                   |                            |winuae/releases/InstallWinU
                   |                            |AE5200.msi
                 CC|[e-mail] |
                   |, [e-mail]      |

[Bug 56371] WinUAE 5.2.0 running under Wine 9 under Fedora 39

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |source

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|WinUAE 5.2.0 running under  |WinUAE: JIT error
                   |Wine 9 under Fedora 39      |

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Bernhard Übelacker  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|https://download.abime.net/ |https://download.abime.net/
                   |winuae/releases/InstallWinU |winuae/releases/InstallWinU
                   |AE5200.msi                  |AE5200_x64.msi

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Andrew Nguyen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Nguyen  ---
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.

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

--- Comment #3 from Andrew Nguyen  ---
Created attachment 76445
  --> https://bugs.winehq.org/attachment.cgi?id=76445
WINEDEBUG=+relay,+seh,+tid,+virtual trace

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|other                       |Linux

--- Comment #4 from Ken Sharp  ---
The 32-bit version of WinUAE works correctly?

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

--- Comment #5 from Andrew Nguyen  ---
(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.

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |win64

[Bug 56371] WinUAE: JIT error

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56371

--- Comment #6 from Andrew Nguyen  ---
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.