[Solved] Toonstruck crashes on aarch64

[vanfanel]

Hi there,

I usually build an aarch64 version of Scummvm (not so exotic, since ARM is going aarch64 anyway).
Thing is, Toonstruck works well on x86_64 but not on aarch64, where it crashes when I click on the "Start a New game" option of the menu.
This is what gdb has to say:

Code: Select all

pi@raspi:~/scummvm$ gdb ./scummvm  
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./scummvm...done.
(gdb) r
Starting program: /home/pi/scummvm/scummvm 

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fbdcd51c0 (LWP 5531)]
[New Thread 0x7fbd4d41c0 (LWP 5532)]
[New Thread 0x7fbccd31c0 (LWP 5533)]
WARNING: Could not find theme 'scummremastered' falling back to builtin!
User picked target 'toon' (gameid 'toon')...
  Looking for a plugin supporting this gameid... Toonstruck
  Starting 'Toonstruck'

Thread 1 "scummvm" received signal SIGSEGV, Segmentation fault.
__memcpy_generic () at ../sysdeps/aarch64/multiarch/../memcpy.S:170
170	../sysdeps/aarch64/multiarch/../memcpy.S: No such file or directory.
(gdb) 
(gdb) bt
#0  __memcpy_generic () at ../sysdeps/aarch64/multiarch/../memcpy.S:170
#1  0x0000007fbdef88b8 in Toon::ToonEngine::setPaletteEntries (this=0x5555cf4590, palette=0x0, offset=1, num=128)
    at engines/toon/toon.cpp:1387
#2  0x0000007fbdee0264 in Toon::Picture::setupPalette (this=0x5556983d00) at engines/toon/picture.cpp:155
#3  0x0000007fbdef9544 in Toon::ToonEngine::loadScene (this=0x5555cf4590, SceneId=4, forGameLoad=false)
    at engines/toon/toon.cpp:1538
#4  0x0000007fbdf00958 in Toon::ToonEngine::newGame (this=0x5555cf4590) at engines/toon/toon.cpp:3198
#5  0x0000007fbdef7580 in Toon::ToonEngine::run (this=0x5555cf4590) at engines/toon/toon.cpp:1143
#6  0x00000055556be9e0 in runGame (plugin=0x5555b312f0, system=..., edebuglevels=...) at base/main.cpp:280
#7  0x00000055556bf768 in scummvm_main (argc=1, argv=0x7ffffff5c8) at base/main.cpp:562
#8  0x00000055556bc960 in main (argc=1, argv=0x7ffffff5c8) at backends/platform/sdl/posix/posix-main.cpp:45

So, it seems that

Code: Select all

Toon::ToonEngine::setPaletteEntries

is receiving a palette pointing to 0x0, and this is a problem on aarch64 but not in x86_64, for some reason.
Is that supposed to happen?

[Praetorian]

Is that supposed to happen?

Probably not supposed to happen, but I don't know if any of the dev team are testing aarch64 builds.

I'd suggest to also open a ticket for this in the scummvm bug tracker.
Is only Toonstruck affected by the way?

[vanfanel]

Probably not supposed to happen, but I don't know if any of the dev team are testing aarch64 builds.

I'd suggest to also open a ticket for this in the scummvm bug tracker.
Is only Toonstruck affected by the way?

Done, I have opened a ticked here:
https://bugs.scummvm.org/ticket/11319#ticket

I can see the Toon::ToonEngine::setPaletteEntries method is doing a memcpy with that 0x0 pointer, so no wonder that it segfaults...
And yes, I have only seen it happen on Toonstruck (I have not tried every Scummvm supported game, but the function where it segfaults is in the "toon" engine which only seems to support this game).

[vanfanel]

Is this working on Android for 64bit ARM system? Just curious.

[carlo_bramini]

I would like to suggest an useful (at least, for me it is) method for testing SCUMMVM for different platforms quite easily.
The only prerequisite is the presence of linux and QEMU-USER.
QEMU is an emulator that pehaps you already know and, besides the emulation of a total system like VirtualBox, allows also to emulate just the CPU.
All other resources are taken directly from the kernel and its connected device.
This type of emulation is called QEMU-USER.
Debian provides a wiki page with the steps for installing it, which can be resumed as:

Code: Select all

apt-get install qemu binfmt-support qemu-user-static
dpkg --add-architecture arm64
apt-get update
apt-get install libc6:arm64

After these lines, you can run basic Aarch64 applications transparently.
A software like SCUMMVM surely requires additional libraries (fluidsynth, readline, etc), but adding them is not difficult to do. Perhaps, a developer with the copy of the game that works on his PC but it seems to crash on a different hardware, could try this method for debugging. After the installation of QEMU-USER, this type of testing becomes easy, at least in my opinion.

Perhaps, some of you already knew about that, but I took the chance to report this tip that usually helps me a lot.
I hope that you will find it useful.

Sincerely.

[Praetorian]

Is this working on Android for 64bit ARM system? Just curious.

Sorry it took me this long to reply on this matter, but I've tested it in the current build of Android ARM64 v8a build and it seems to be working ok. Launch video plays ok, Intro video option plays ok, Start new game plays ok and gameplay works fine as well as Load and Save and moving through screens.

I took a quick look at the code too and it seems that, while there could be some check to prevent the pointer being NULL, this should happen only if a required data file is not found, or is corrupted. The pertinent data file in this case is a .CPS file that resides in the ACT1\PAL1LAN\PAL1LAN.PAK file for the scene (id: 4).

So some possibilities could be that the specific PAK file is corrupted, or missing? Or that the unpack method resources()->openPackage() has some issues with some aarch64 systems (I'll look into this further).

[carlo_bramini]

Hello,
I compiled the latest sources of ScummVM for Aarch64 on linux Debian and I tested it with the german demo version of the game that I downloaded from this site: the game starts, it plays the intro video and when I select New Game the gameplay starts without crashes.
Perhaps, the demo version is not enough to replicate the defect (if it exists), however I also wanted to test if I could run the same ScummVM executable also under QEMU-User emulation and it seems that is has been a positive result.

If I can say my opinion:
* it is interesting that the user says that the game works fine on PC in x86_64, but it does not on its Raspberry PI.
* I suppose that you copied the game on your SD Card. Try to play the game on PC by mounting the SD Card and use directly those files, for excluding some corruptions.
* Could I ask if you downloaded a precompiled ScummVM somewhere or you compiled it? Perhaps it is just that executable to have some problems.

Please excuse my intrusion and I hope that you will find it useful.
Sincerely.

[vanfanel]

Thanks everyone who answered here. The game is now working nicely on the Pi3b+ in 64bit mode after updating libraries and gcc compiler, and re-building latest stable version of scummvm! Thanks for your ideas

[Praetorian]

Thanks everyone who answered here. The game is now working nicely on the Pi3b+ in 64bit mode after updating libraries and gcc compiler, and re-building latest stable version of scummvm! Thanks for your ideas

That's great news.
I've closed the relevant ticket, referencing your above quote here:
https://bugs.scummvm.org/ticket/11319#ticket

[vanfanel]

Thanks everyone who answered here. The game is now working nicely on the Pi3b+ in 64bit mode after updating libraries and gcc compiler, and re-building latest stable version of scummvm! Thanks for your ideas

That's great news.
I've closed the relevant ticket, referencing your above quote here:
https://bugs.scummvm.org/ticket/11319#ticket

I was about to close it, just remembered today about the ticket! Thanks, Praetorian