Amiberry broken on Pi 4/Buster

sleve_mcdichael

Amiberry install from both source/binary, gives the error:

malloc(): unsorted double linked list corrupted
Aborted

https://github.com/BlitterStudio/amiberry/issues/1366

https://github.com/BlitterStudio/amiberry/discussions/1295

Replacing amiberry binary with one extracted from the releases page, does work:

https://github.com/BlitterStudio/amiberry/releases/tag/v5.7.1

https://github.com/BlitterStudio/amiberry/releases/download/v5.7.1/amiberry-v5.7.1-debian-buster-armhf-rpi4.zip

Discussions on github point to a missing capsimg.so library, which is accounted for in the RP scriptmodule, but absent from the package repository (from the 5.7.1 version used, anyway -- it is present in the current master branch.)

It looks like it used to be a submodule, but then rolled the sources in manually?

https://github.com/BlitterStudio/amiberry/pull/1374

I don't know what to do with any of that. I've only just started to explore the amiga and its library, and hit this immediate roadblock.

ETA: in the build log it looks like it's still cloning into the capsimg submodule but then something goes wrong and it don't get the output file in the end (L129):

cp: cannot stat '*capsimg.so': No such file or directory

https://pastebin.com/hJnFf84U

mitu

[...]

Discussions on github point to a missing capsimg.so library, which is accounted for in the RP scriptmodule, but absent from the package repository (from the 5.7.1 version used, anyway -- it is present in the current master branch.)

The capsimg.so is indeed missing (binary or source install) and this should be fixed in the build script. However, I don't think that's the cause of the crash - even with the .so included it still crashes. The binary package from the Amiberry releases does indeed work, despite the fact that the .zip also doesn't have the capsimage.so file in the plugins folder.

I'll try to see where the crash occurs and what's causing it.

BuZz

I noticed an error when building recently (relating to capsimg location). It's on my list to check.

mitu

@BuZz Yes, the copying of the campsimg.so build artifact to $md_build/plugins is not working, but the error occurs whether that's fixed or not. I'm starting to suspect is configuration related, since the backtrace from the crash is pointing to a simple static var initialization - can't see how that triggers a SIGABRT.

mitu

Hm, after fixing the capsimg.so plugin installation and trying to compare our build to the one produced upstream, I can't reproduce the issue anymore.

@sleve_mcdichael can you test to see if https://github.com/RetroPie/RetroPie-Setup/pull/3978 fixes the issue for you ? Make sure you have the necessary Kickstart files in $HOME/RetroPie/BIOS/amiga just to rule out any missing model KS files.

EDIT: PR has been merged, so you can just update RetroPie-Setup then try a source update.

sleve_mcdichael

@mitu yes install from source works now, thanks.

Re: kickstart roms -- I had a hard time figuring out which of the many different given filenames I was supposed to be using, but I think I've got it mostly sorted out, now.

...

I've found that, using BrutalFootball_v1.21_CD32.lha for example, none of the following:

kick40063.A600 #as distributed, "somewhere"
kick40063.a600
40063.A600
40063.a600 #as named in the error message

...none of those work. The error shown is as:

...which appears to be looking for 40063.a600 even while that file is present, and does not work.

However, that same file renamed as either of:

Kickstart v3.1 rev 40.63 (1993)(Commodore)(A500-A600-A2000)[!].rom
Kickstart v3.1 rev 40.063 (1993)(Commodore)(A500-A600-A2000)[!].rom

(nb. .63 vs .063) ...both these does work.

On the Amiberry github, I do see this filename format for several of the kickstarts, but I still don't know what to do with these last two remaining:

42baa124    kick34005.CDTV     89da1838a24460e4b93f4f0c5d92d48d
9e6ac152    kick39106.A4000    9b8bdd5a3fd32c2a5a6f5b1aefc799a5

Maybe these just aren't used by Amiberry? I see the kick34005.CDTV listed only in the lr-puae section, and the other one doesn't seem to be mentioned anywhere...

sleve_mcdichael

malloc(): unsorted double linked list corrupted
Aborted

Not sure this is really fixed, after all. I am now getting this same error again when re-installing Amiberry. As before, no error when using binary from github release page, but does error when using RetroPie version (built from source or precompiled. RPi4.)

Investigating, it seems related to amiberry.conf:

Using github binary, works with or without amiberry.conf; is created if not present.
using RetroPie binary, does not work without. However, if amiberry.conf exist with a defined rom_path= to the kickstarts, then RP binary does work, and conf is populated with remaining values.
oddly, it also still works if conf contains only floppy_sounds_dir=/opt/retropie/emulators/amiberry/data/floppy_sounds/

...so it's just these two?

Seems yes: if both rom_path and floppy_sounds_dir are removed from the working conf, then RP version aborts with error; but if either one is present (even as the only entry), then it works fine, and fills in remaining values, including whichever of these two was left out.

This COULD be work-around by pre-populate conf with rom_path value, but it don't explain why github version still work fine with no conf at all.

     # set various media paths to the 'amiga' rom folder
-    if [ -f "$md_inst/conf/amiberry.conf" ]; then
     iniConfig "=" "" "$md_inst/conf/amiberry.conf"
+    iniSet "rom_path" "$biosdir/amiga"
     iniSet "floppy_path" "$romdir/amiga"
     iniSet "harddrive_path" "$romdir/amiga"
     iniSet "cdrom_path" "$romdir/amiga"
     iniSet "lha_path" "$romdir/amiga"
-    fi
+    chown "$__user":"$__group" "$md_inst/conf/amiberry.conf"

Current script module does set some paths in conf, but the behavior confuse me. Since the conf file is not exist on clean install, these values are not set at first. Defaults are then used ($md_inst) for some time until (optional) if user chooses to reinstall/update amiberry. Only at that time, file DOES exist, and so paths are now CHANGE to use $romdir instead of $md_inst like they had been using. Is this really the intended way, and if so then why?

EDIT: i maybe didn't test enough -- the "remaining values are filled" in the .conf, only when run the +Start Amiberry.sh. When launch by one of the .lha roms instead, no values are filled, but the game still seem to work. They load and play anyway, did not test saving. But it's late and I've shut down for the night. Will test saving tomorrow.

sleve_mcdichael

EDIT: i maybe didn't test enough -- the "remaining values are filled" in the .conf, only when run the +Start Amiberry.sh. When launch by one of the .lha roms instead, no values are filled, but the game still seem to work. They load and play anyway, did not test saving. But it's late and I've shut down for the night. Will test saving tomorrow.

Yes, saving works:

pi@retropie:/opt/retropie/configs/amiga/amiberry $ cat conf/amiberry.conf 
rom_path=/home/pi/RetroPie/BIOS/amiga
floppy_path=/home/pi/RetroPie/roms/amiga
harddrive_path=/home/pi/RetroPie/roms/amiga
cdrom_path=/home/pi/RetroPie/roms/amiga
lha_path=/home/pi/RetroPie/roms/amiga
pi@retropie:/opt/retropie/configs/amiga/amiberry $ ls -l whdboot/save-data/Savegames/ItCameFromTheDesert/
total 16
-rwxr----- 1 pi pi 12444 Dec 20 11:36 ICFTD
pi@retropie:/opt/retropie/configs/amiga/amiberry $ file whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD 
whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD: data

...save file exist, and I can quit and restart amiberry, then re-load the save in-game.

It's the same with either github/retropie version binary: no values are written (and file NOT created) when loading from .lha rom, saves still work at default location. Values are written (and file is created, with github version) when launch from +Start Amiberry.sh.

Edit: Launch from .lha rom, then open amiberry config and change eg. Rom path: all values are written to file (for both RP version with minimal conf, or github version with no conf.) But, if open config then quit with no change == no write values.