Cxbx-reloaded: Cxbx-R is broken under Wine since the introduction of the loader

[barolo]

Quick summary

Emulation of any game doesn't start.

Details

GUI launches fine, configuration too, after pressing start emulation nothing happens or memory related error pops out:

Switching to the mode without the loader doesn't help.
Games are ripped properly, they work fine under Windows.

I seems that the bug was introduced during the transition to loader and the commit:

Author: ergo720 <[email protected]>
Date:   Fri Jul 12 16:00:52 2019 +0200

System Configuration:

Linux 5.8.0
AMD RAVEN APU 2400G
Wine versions: any, up to 5.14

Additional Information (if any):

[PatrickvL]

The "failed to reserve required memory ranges" popup message indicates that the available virtual memory ranges under wine don't correspond to those under windows (because this step does work under windows OS itself). So there's a fair chance the problem lies with wine, or maybe even the underlying Linux OS.

[PatrickvL]

In 2017/2018, we had a similar problem with wine, that didn't allow loading executables at the lowest possible address (0x0001 0000), which was fixed (in wine) specifically for our use-case.

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

[PatrickvL]

First thing we need to establish, is which virtual memory address range(s) cannot be reserved. Perhaps we can work around that one(s). And if not, maybe we can file another report in the wine issue list...

[ergo720]

The wine hack was related to the tiled memory region, so adding this code (Start == TILED_MEMORY_BASE) ? MiB(64) : Size at https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/71dc7e988ee9861f2d1c30ef8e968e7dd88e25d7/src/common/ReserveAddressRanges.cpp#L104 should fix it. Reserving 128 MiB for the tiled region on 128 MiB systems is actually not needed in the first place so we can avoid detecting wine at this point. Also, the tiled region does not have the MAY_FAIL flag and so it will lead to that error if it fails reservation.

[ergo720]

Actually, the above might not be the problem since line https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/e6b2ed88af52207e3df544b692ee7acb2ef521f3/src/common/AddressRanges.cpp#L58 shows that the tiled region is already using a 64 MiB size, so it's probably something else.

[barolo]

It's hard to debug as kernel debugging either to file or console doesn't seems to work, or to file works once in a thousand tries

[PatrickvL]

It might be possible to add details on all failed memory range reservations to the popup message, so that we can start investigating those specific ranges

[RadWolfie]

For loader process, it will be some work requirement in order to do that. As for non-loader, should be easy to do than loader method.

However, non-loader shouldn't fail since it does already reserved 64MiB space in placeholder variable from the executable itself. The issue might be elsewhere.

---

To be clear what I had experienced when I was testing with wine (5.6 dev) in VM during loader pull request to main branch.

• Half or most of the time produce "failed to reserve required memory ranges" message.
  
  
  
  • Then unable to restart emulation unless restart GUI.
  
  
• Log to console does work except doesn't work to file.
  
  
  
  • After system and wine (5.14) updates, both console and file logs doesn't work.
  
  
• Loader method can lockup at 100%. I'm unable to determine the cause, since it occur within loader executable than emulator module.
  
  
  
  • (I had confirmed it by debug emulator entry point with a test popup message which didn't popup.)
  
  

[barolo]

As an enduser I care for it to run, no matter which way ;)

[barolo]

I've basically bisected it, checking how far up I could go with the builds until it's broken. 2a23634c770241ef2f211bf4b49bea2eaca124d7 is the last working. Aprill 14 2020 one still works, even with newest wine.
So yeah, the loader.

[Loomeh]

When I use CXBX-R On Wine (Pop!_OS) and click 'Start' on the 'Emulation' tab nothing happens, not even a single error message, just nothing. I've tried builds from September 2020, August 2020 and July 2020 and none of those work either.

[barolo]

Erm, the comment right above you says athat you can't go beyond April 14, so it's not surprise that yours aren't working @Loomeh

[RadWolfie]

UPDATE: After some discussion from the group and attempt to try something different.
Here's the result:

@ergo720 was able to determine which address range did not allocate whole range. An attempt to try comment FLASH_DEVICE4_BASE out did not work. The next thing I did is comment out FLASH_DEVICE3_BASE which no longer cause loophole issue with loader method.

Further suggestion is to add MAY_FAIL flag to FLASH_DEVICE3_BASE range. I do not get any loophole from loader and is able to enter emulator's entry point. So... there is an issue from cxbxr-ldr's codebase for the loophole.

P.S. double click cxbxr-ldr.exe directly does output to console window with a popup message dialog for incorrect usage.