Wine WOW64 8.18 hangs on wineboot about box64

[500InternalError]

was this type of error supposed to be fixed 0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7 ? because I am still seeing very many of them.

Could it be caused by your kernel doesn't have full 48 bit address space? I know wine 8.18 on android also has this problem, and android only have 39 bit virtual address, while wine presumes you have 48 bit address space and allocates memory from higher space which is unavailable. Modifying address space limit in dlls/ntdll/unix/virtual.c fixes this issue for me

[ptitSeb]

Interesting. I'll take a look, thanks for the test and the binary.

[m1m1k4tz]

This looks like the same issue in #999 and #487

[ptitSeb]

I don't think so; this one have is on a 4K Pagesize.

[m1m1k4tz]

That’s weird bc I get it too when I used the 16k kernel too also I’m not sure if the asahi fedora builder I used had the 16k kernel by default or the 4k kernel it felt faster so I think it came with that before I switched to the official remix 🤔

[ptitSeb]

@theofficialgman I just tried with latest box64, and I could not reproduce the issue on my side. Can you check if you still have the issue on your side with latest box64?

[theofficialgman]

will do when I get home later today (so a few hours from now)

[theofficialgman]

@ptitSeb I updated to 6ef2b22 (latest master) and it still hangs for me

[m1m1k4tz]

@theofficialgman I just tried with latest box64, and I could not reproduce the issue on my side. Can you check if you still have the issue on your side with latest box64?

What desktop environment?

[ptitSeb]

@ptitSeb I updated to 6ef2b22 (latest master) and it still hangs for me

Is it from an empty wineprefix or from a older one?

[m1m1k4tz]

I get the same error aswell on the latest box64 on the m1

[m1m1k4tz]

I don't think so; this one have is on a 4K Pagesize.

Actually yeah I think ur right I think the 16k pi issue is the same one I’m having tho but I’m not sure if the vm method for asahi linux would work on the new pi too

[ptitSeb]

I don't think so; this one have is on a 4K Pagesize.

Actually yeah I think ur right I think the 16k pi issue is the same one I’m having tho but I’m not sure if the vm method for asahi linux would work on the new pi too

But your log shows PageSize:4096?

[m1m1k4tz]

Sorry yeah that’s what I meant the other issue I linked that was about the pi is what I was taking about

[theofficialgman]

@ptitSeb I updated to 6ef2b22 (latest master) and it still hangs for me

Is it from an empty wineprefix or from a older one?

I was using an older wineprefix. I just deleted the wineprefix and tested again and it still hangs.

[theofficialgman]

@ptitSeb lets keep the discussion about this issue here
I can reproduce the issue on two test systems (both clean/empty wine prefixes): ubuntu jammy 22.04 and debian bookworm 12. I have not tested earlier versions of debian/ubuntu as of now.

[ptitSeb]

I don't thinks it's the OS version. I tried on Ubuntu 22.04 lts on my side, and it worked. Must be something on the system hardware. Amount of memory or cpu capabilities maybe. Or something about box64 build option maybe.
I assume you are testing on some NVidia hardware? jetson something or Switch (all of that I don't have anyway).
I'm on an ADLINK + NVidia 1050 on my side (that's a very powerfull system).
I tried also quickly on a Lenovo X13s with Armbian and it was working too.
Did you tried on some RPi?

[theofficialgman]

I don't thinks it's the OS version. I tried on Ubuntu 22.04 lts on my side, and it worked. Must be something on the system hardware. Amount of memory or cpu capabilities maybe. Or something about box64 build option maybe. I assume you are testing on some NVidia hardware? jetson something or Switch (all of that I don't have anyway). I'm on an ADLINK + NVidia 1050 on my side (that's a very powerfull system). I tried also quickly on a Lenovo X13s with Armbian and it was working too. Did you tried on some RPi?

Multiple test systems are being used:
Jammy 22.04 on nintendo switch (4GB ram) -> box64 builds produced with this CI with TEGRAX1 target https://github.com/Pi-Apps-Coders/box64-debs/blob/master/create-deb.sh#L59

PiOS Bookworm on Pi5 (8GB ram) (4K pagesize kernel) -> box64 builds produced with this CI with ARM64 target https://github.com/Pi-Apps-Coders/box64-debs/blob/master/create-deb.sh#L57

I have more ARM64 hardware that I could check (Jetson Orin Nano, Pi3, Pi4) but have not checked on them.
As you can see in the CI, all builds are made with GCC-8 (for compatibility reasons). I can check later if building locally and using a newer compiler mitigates the issue or not.

[ptitSeb]

Can you try to gdb inside the frozen process and see how many threads are created and what are the backtraces there?

[ksco]

@theofficialgman can you try again with the latest main? it might just work now.

[theofficialgman]

@ptitSeb your memory idea looks to be correct

@ksco on the latest commit now I don't hang but instead get a lot of errors in log. I have no such try_map_free_area mmap errors in wine 8.17

Using native(wrapped) librt.so.1
002c:err:virtual:map_fixed_area out of memory for 0x6fffffce0000-0x6fffffff9000
002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffcd0000-0x7ffffffe9000, unix_prot 0x7.
002c:err:virtual:map_fixed_area out of memory for 0x6fffffb50000-0x6fffffcd9000
002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffe60000-0x7ffffffe9000, unix_prot 0x7.
002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffe60000-0x7ffffffe9000, unix_prot 0x7.
002c:err:virtual:map_fixed_area out of memory for 0x6fffff5f0000-0x6fffffb4a000
002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7.
002c:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7.
0034:err:virtual:map_fixed_area out of memory for 0x6fffffce0000-0x6fffffff9000
0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffcd0000-0x7ffffffe9000, unix_prot 0x7.
0034:err:virtual:map_fixed_area out of memory for 0x6fffffb50000-0x6fffffcd9000
0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffe60000-0x7ffffffe9000, unix_prot 0x7.
0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffe60000-0x7ffffffe9000, unix_prot 0x7.
0034:err:virtual:map_fixed_area out of memory for 0x6fffff5f0000-0x6fffffb4a000
0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7.
0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7.
003c:err:virtual:map_fixed_area out of memory for 0x6fffffce0000-0x6fffffff9000

are these safe wine errors that I should ignore and caused by box64 or should I report them to wine as a regression?

[ksco]

yep I'm seeing these errors too, it's an 8.18-only thing. I haven't investigated it yet, so idk what's wrong. Anyway these logs don't seem to affect the actual behavior.

[theofficialgman]

my guess is it is caused by this change
https://gitlab.winehq.org/wine/wine/-/commit/30c8da1c9dd8dcc1aee2d328a5fdf7edbf6c7978

seems to me the only thing that changed with mmap in wine between 8.17 and 8.18

[theofficialgman]

Since the bug itself seems fixed I will close this

[ksco]

yeah, this one looks very suspicious, but most likely it's a box64 side issue, maybe some more corner cases need to be cared for.

[theofficialgman]

Re-opening as this change d9a4fed caused a regression on all wine versions on one of my test systems: (Pi5 8GB Ram Bookworm ARM64 with 4K kernel). the issue does not occur on one of my other test systems (nintendo switch, 4GB ram)

clean/empty wine prefix, wineboot hangs during wine mono removeuserinstalls-x86.exe execution
happens on wine-8.17 and wine-8.18 on versions of box64 after that commit

pi-apps installs gecko and mono into wine as recommended by wine documentation. running wineboot first time as such will install gecko and mono into any wineprefix.

simplified install code

version=8.18

error() {
  echo "$@"
  exit 1
}

sudo rm -rf /opt/wine-${version}

# Download wine to /opt
wget https://github.com/Pi-Apps-Coders/files/releases/download/large-files/wine-${version}.tar.gz -O /tmp/wine-${version}.tar.gz || error 'Failed to download wine!'
sudo tar -xvf /tmp/wine-${version}.tar.gz -C /opt || error 'Failed to extract wine!'
rm -f /tmp/wine-${version}.tar.gz

#edit wine.inf to disable mime-associations. Nobody wants to double-click a text file, wonder why nothing is happening, then watch 15 Wine notepad windows pop up. Ask me how I know.
sudo sed -i 's/winemenubuilder.exe -a -r/winemenubuilder.exe -r/' /opt/wine-${version}/share/wine/wine.inf #See: https://askubuntu.com/a/400430

#download winetricks
wget -O /tmp/winetricks "https://raw.githubusercontent.com/theofficialgman/winetricks/master/src/winetricks" || exit 1
sudo mv /tmp/winetricks /opt/wine-${version}/bin/winetricks || error "Failed to move winetricks script to /opt/wine-${version}/bin folder!"
sudo chmod +x /opt/wine-${version}/bin/winetricks

#download Mono to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Mono#Versions, use Mono 8.0.0 for Wine 8.11
#wine mono pacakge is called -x86 but contains both x86 and x86_64 binaries
sudo mkdir -p /opt/wine-${version}/share/wine/mono
wget -O "/tmp/wine-mono-8.0.0-x86.tar.xz" 'https://dl.winehq.org/wine/wine-mono/8.0.0/wine-mono-8.0.0-x86.tar.xz' || exit 1
sudo tar -xvf "/tmp/wine-mono-8.0.0-x86.tar.xz" -C "/opt/wine-${version}/share/wine/mono" || exit 1
rm -f "/tmp/wine-mono-8.0.0-x86.tar.xz"

#download Gecko to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Gecko, use Gecko 2.47.4 for Wine 8.11
sudo mkdir -p /opt/wine-${version}/share/wine/gecko
wget -O "/tmp/wine-gecko-2.47.4-x86_64.tar.xz" 'https://dl.winehq.org/wine/wine-gecko/2.47.4/wine-gecko-2.47.4-x86_64.tar.xz' || exit 1
sudo tar -xvf "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"  -C "/opt/wine-${version}/share/wine/gecko" || exit 1
rm -f "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"

clear prefix

rm -rf ~/.wine

run wineboot

version=8.18
/opt/wine-${version}/bin/wine wineboot

[ptitSeb]

github auto-closed the ticket based on the title on the commit :(...

Anyway, @theofficialgman @ksco if you can try that new commit on your side. It helps on my side, but not sure if it will work fully for you.

[ksco]

Ah, mmap stuff are complicated!

[theofficialgman]

Anyway, @theofficialgman @ksco if you can try that new commit on your side. It helps on my side, but not sure if it will work fully for you.

was this type of error supposed to be fixed 0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7 ? because I am still seeing very many of them.

Regardless I end up hanging later in the process during winetricks install of vcrun2008

edit: cleared wine prefix and tried again and this time it all completed without hanging. might just be unstable

[ksco]

Ah, I’m sure my RISC-V SBC uses a 39 bit virtual address (i.e. Sv39) too!

[500InternalError]

However wine developers don't recommend to modify that limit, so a better choice is to rebuild kernel with 48 bit address support. But on android you have no choice : )

[ptitSeb]

Might be related to #1035

I guess this ticket can be closed now, wineboot should not hang anymore with latest box64.

[mcagabe19]

Might be related to #1035

I guess this ticket can be closed now, wineboot should not hang anymore with latest box64.

It still does hang in termux proot no idea

[ptitSeb]

Might be related to #1035
I guess this ticket can be closed now, wineboot should not hang anymore with latest box64.

It still does hang in termux proot no idea

And it works on my side.

Note that I do not test on termux, so you need to provides logs and details.

[mcagabe19]

Might be related to #1035
I guess this ticket can be closed now, wineboot should not hang anymore with latest box64.

It still does hang in termux proot no idea

And it works on my side.

Note that I do not test on termux, so you need to provides logs and details.

My bad I can confirm it works in termux proot I was not using latest commit 😅

[theofficialgman]

was this type of error supposed to be fixed 0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7 ? because I am still seeing very many of them.

Could it be caused by your kernel doesn't have full 48 bit address space? I know wine 8.18 on android also has this problem, and android only have 39 bit virtual address, while wine presumes you have 48 bit address space and allocates memory from higher space which is unavailable. Modifying address space limit in dlls/ntdll/unix/virtual.c fixes this issue for me

I don't think so, especially since it happens on tegra and raspberry pi kernels... @500InternalError how can I check in the kernel config or with a running system in userspace?

[500InternalError]

was this type of error supposed to be fixed 0034:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7fffffa90000-0x7ffffffea000, unix_prot 0x7 ? because I am still seeing very many of them.

Could it be caused by your kernel doesn't have full 48 bit address space? I know wine 8.18 on android also has this problem, and android only have 39 bit virtual address, while wine presumes you have 48 bit address space and allocates memory from higher space which is unavailable. Modifying address space limit in dlls/ntdll/unix/virtual.c fixes this issue for me

I don't think so, especially since it happens on tegra and raspberry pi kernels... @500InternalError how can I check in the kernel config or with a running system in userspace?

I check this by cat /proc/<pid>/maps and see is the highest address always bounded by 0x7fffffffff. If true then you presumably have 39 bit address space. Don't know if this the right way to check this.

[theofficialgman]

I assume you are talking about the limits here -> https://github.com/wine-mirror/wine/blob/3a8d71041c159d76a76856867caa1de8ca297151/dlls/ntdll/unix/virtual.c#L155-L185

@ptitSeb do you have any thoughts? I think it is intentional that it is reporting this https://gitlab.winehq.org/wine/wine/-/commit/30c8da1c9dd8dcc1aee2d328a5fdf7edbf6c7978 . I assume that these inaccessible memory areas are carveouts takes by various devices in the kernel.

[theofficialgman]

@ptitSeb Wine-8.19 seems to be hanging again on removeuserinstalls-x86.exe from winemono on an empty prefix

version=8.19

error() {
  echo "$@"
  exit 1
}

sudo rm -rf /opt/wine-${version}

# Download wine to /opt
wget https://github.com/Pi-Apps-Coders/files/releases/download/large-files/wine-${version}.tar.gz -O /tmp/wine-${version}.tar.gz || error 'Failed to download wine!'
sudo tar -xvf /tmp/wine-${version}.tar.gz -C /opt || error 'Failed to extract wine!'
rm -f /tmp/wine-${version}.tar.gz

#edit wine.inf to disable mime-associations. Nobody wants to double-click a text file, wonder why nothing is happening, then watch 15 Wine notepad windows pop up. Ask me how I know.
sudo sed -i 's/winemenubuilder.exe -a -r/winemenubuilder.exe -r/' /opt/wine-${version}/share/wine/wine.inf #See: https://askubuntu.com/a/400430

#download winetricks
wget -O /tmp/winetricks "https://raw.githubusercontent.com/theofficialgman/winetricks/master/src/winetricks" || exit 1
sudo mv /tmp/winetricks /opt/wine-${version}/bin/winetricks || error "Failed to move winetricks script to /opt/wine-${version}/bin folder!"
sudo chmod +x /opt/wine-${version}/bin/winetricks

#download Mono to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Mono#Versions, use Mono 8.1.0 for Wine 8.19
#wine mono pacakge is called -x86 but contains both x86 and x86_64 binaries
sudo mkdir -p /opt/wine-${version}/share/wine/mono
wget -O "/tmp/wine-mono-8.0.0-x86.tar.xz" 'https://dl.winehq.org/wine/wine-mono/8.1.0/wine-mono-8.1.0-x86.tar.xz' || exit 1
sudo tar -xvf "/tmp/wine-mono-8.1.0-x86.tar.xz" -C "/opt/wine-${version}/share/wine/mono" || exit 1
rm -f "/tmp/wine-mono-8.1.0-x86.tar.xz"

#download Gecko to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Gecko, use Gecko 2.47.4 for Wine 8.11
sudo mkdir -p /opt/wine-${version}/share/wine/gecko
wget -O "/tmp/wine-gecko-2.47.4-x86_64.tar.xz" 'https://dl.winehq.org/wine/wine-gecko/2.47.4/wine-gecko-2.47.4-x86_64.tar.xz' || exit 1
sudo tar -xvf "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"  -C "/opt/wine-${version}/share/wine/gecko" || exit 1
rm -f "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"

clear prefix

rm -rf ~/.wine

run wineboot

version=8.19
/opt/wine-${version}/bin/wine wineboot

[theofficialgman]

happens on wine-8.18 too and wine-8.18 and wine-8.19 were both previously working, indicating this is the result of a recent box64 change.

[theofficialgman]

Based on pi-apps statistics, since no users have been able to install on 11/11/2023, and the current box64 build is b82d9d1, and yesterday half of the normal were able to install I would guess that the issue is between the two days ago build or included in 675336d and b82d9d1

[theofficialgman]

@ptitSeb seems already fixed in latest master.... sorry for the report
0.2.5+20231108T064822.ca8ad5e-1 works
0.2.5+20231109T070107.675336d-1 works
0.2.5+20231110T063706.113c879-1 works
0.2.5+20231111T063625.b82d9d1-1 hangs
0.2.5+20231111T213828.70e4bd4-1 works

[ptitSeb]

Can we close this ticket now?