BACKENDS: WII: Wii crashes on Daily Build

[CrystalBen]

Hi, when i wanna use the Daily Build of ScummVM its always crash when i add
a new Game, i also tried the Stable Build and it not crashes there. i can add under the Stable Build my Games and play them. Hope someone can help me on the
Daily Build Version for the Wii

[digitall]

Tested this myself with ScummVM v2.7.0 release and the latest daily build i.e. 2.8.0-git-073e0229d. As reported, v2.7.0 detects games fine including Mass Add which is slow, but completes fine.

However, the v2.8.0git nightly crashes detecting a single game. I have tried removing all the newer plugins from the folder, but the crash persists so this is either something to do with the Wii build environment with buildbot or a change to backend / engine code since v2.7.0.

Will try testing with the buildbot v2.7.0 stable nightly to see if that replicates the issue: ​https://buildbot.scummvm.org/dailybuilds/stable/wii-stable-c4f24b2f.tar.xz

If so, that would indicate a build environment issue with the buildbot vs. release build environment from the Porter...

[digitall]

Right. The v2.7.1pre build I linked above detects fine and does _NOT_ crash... so this is a regression between v2.7.0 and current master. SIGH.

[dwatteau]

I could try having a look at bisecting this, maybe this week, maybe later this month, unless someone beats me to it first.

[dwatteau]

Investigating a bit with Dolphin (at the moment), it looks like this *may* be related to the number of plugins, since the problem disappears when I remove all plugins starting from a to i included. But it doesn't appear to be related to a plugin in particular.

Dolphin gives the following output when the crash happens:

IntCPU: Unknown instruction 00000000 at PC = 906a1ea8  last_PC = 00000000  LR = 90070720

Trying to see if a bisect gives something...

[digitall]

Just a quick update. Have sorted out the Docker build environment for Wii using podman and am running a bisection for this.

My test case is trying a detection for Full Throttle. This crashes to a black crash dump screen in the failure case, though it seems to softlock in some cases as well.

Have narrowed the interval for the regression to 0b7c19a0702d1c..a305fe56d6cb

None of the commits in that interval affect the Wii backend directly, but I suspect that the issue may be an out of memory issue in the detection caused by the AGS and GLK engines (hence why removing plugins a to i may work).

These engines have very large detection entry string lists and I suspect these might be causing an OOM issue.

[digitall]

Bisection complete. To be clear, I have been testing on a real Wii, so a bit slow to go round the test-build loop :)

6cf8b64c270895d1dce5ea07f693969c2188acae is the first bad commit
commit 6cf8b64c270895d1dce5ea07f693969c2188acae
Author: Walter Agazzi <walter.agazzi@…>
Date: Wed Feb 22 02:09:30 2023 +0100

AGS: Add detection for old hour-games

From AGS archives

engines/ags/detection_tables.h | 49 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 47 insertions(+), 2 deletions(-)

[digitall]

That would tend to support my assertion that it may be the size of the AGS and probably the GLK metaengine code.

[digitall]

I modified the previously failing build of 6cf8b64c to move the top four largest plugins to a new plugins-disabled folder i.e. a user could do this modification on a daily build.

These were:
5.3 MB ultima.plg
4.6 MB glk.plg
4.3 MB ags.plg
4.1 MB tsage.plg

The build was then able to do a detection of Full Throttle without crashing out so this again supports my hypothesis.

[digitall]

Still trying to sort out a debugging solution for this. Building a USB Gecko from scratch as purchasing is now not possible, but tricky to get working.

[digitall]

NB: Probably evident from regression point, but v2.7.0 and v2.7.1 releases work fine on Wii (have tested with no issues), but this bug will affect v2.8.0 release unless it is fixed or the workaround detailed previously is applied.