Using --autoload cmdline option results in seg_fault

[giantclambake]

amiberry v5.6.1 / x86-64

I've been aware of this for a while, but didn't immediately report it because Quickstart ->WHDload auto-config method via GUI works fine. I just now crossed paths with it again, trying to define custom actions for the mime-type in qtfm ...ie; either 'lha x %F' to extract arc, or else 'amiberry -G --autoload %F' to run the whdload-game.lha directly.

To recreate;

Obtain known working good .lha archive (referenced target: https://www.whdownload.com/games/A/AddamsFamily_v1.3_0419.lha)

//sanity check// Start amiberry from cmdline, in the GUI goto Quickstart -> WHDload auto-config, and select the archive download above then simply hit start ---- archive should be parsed correctly, and game starts as expected. Quit game/amiberry

At the cmdline, issue 'amiberry --autoload AddamsFamily_v1.3_0419.lha' --- here I hit a segmentation fault (any/all whdload archives)

//tail of dmesg;

[872005.838261] amiberry[12315]: segfault at 0 ip 00007fda03ace4bd sp 00007ffdc0554908 error 4 in libc.so.6[7fda03a45000+154000] likely on CPU 0 (core 0, socket 0)
[872005.838274] Code: ff 0f 00 00 66 0f 60 c9 48 3d bf 0f 00 00 66 0f 60 d2 66 0f 61 c9 66 0f 61 d2 66 0f 70 c9 00 66 0f 70 d2 00 0f 87 03 03 00 00 <f3> 0f 6f 1f 66 0f ef ed f3 0f 6f 67 01 66 0f 6f f3 66 0f 74 d9 66

Running a debug build of amiberry with gdb, leadup to the crash looks like ;

(gdb) next
3684                    SDL_Init(SDL_INIT_EVERYTHING) != 0
(gdb) next
[New Thread 0x7fff7753e6c0 (LWP 30066)]
[New Thread 0x7fff692f66c0 (LWP 30067)]
3675            if (
(gdb) next
3697            atexit(SDL_Quit);
(gdb) next
3698            write_log(_T("Sorting devices and modes...\n"));
(gdb) next
3699            sortdisplays();
(gdb) next
3700            enumerate_sound_devices();
(gdb) next
3701            for (int i = 0; i < MAX_SOUND_DEVICES && sound_devices[i]; i++) {
(gdb) next
3702                    int type = sound_devices[i]->type;
(gdb) next
3703                    write_log(_T("%d:%s: %s\n"), i, type == SOUND_DEVICE_SDL2 ? _T("SDL2") : (type == SOUND_DEVICE_DS ? _T("DS") :
(type == SOUND_DEVICE_AL ? _T("AL") : (type == SOUND_DEVICE_WASAPI ? _T("WA") : (type == SOUND_DEVICE_WASAPI_EXCLUSIVE ? _T("WX") : _T(
"PA"))))), sound_devices[i]->name);
(gdb) next
3701            for (int i = 0; i < MAX_SOUND_DEVICES && sound_devices[i]; i++) {
(gdb) next
3705            write_log(_T("Enumerating recording devices:\n"));
(gdb) next
3706            for (int i = 0; i < MAX_SOUND_DEVICES && record_devices[i]; i++) {
(gdb) next
3707                    int type = record_devices[i]->type;
(gdb) next
3708                    write_log(_T("%d:%s: %s\n"), i, type == SOUND_DEVICE_SDL2 ? _T("SDL2") : (type == SOUND_DEVICE_DS ? _T("DS") :(type == SOUND_DEVICE_AL ? _T("AL") : (type == SOUND_DEVICE_WASAPI ? _T("WA") : (type == SOUND_DEVICE_WASAPI_EXCLUSIVE ? _T("WX") : _T(
"PA"))))), record_devices[i]->name);
(gdb) next
3706            for (int i = 0; i < MAX_SOUND_DEVICES && record_devices[i]; i++) {
(gdb) next
3710            write_log(_T("done\n"));
(gdb) next
3712            normalcursor = SDL_GetDefaultCursor();
(gdb) next
3713            clipboard_init();
(gdb) next
3717            ioctl(0, KDGKBLED, &kbd_flags);
(gdb) next
3718            ioctl(0, KDGETLED, &kbd_led_status);
(gdb) next
3719            if (kbd_flags & 07 & LED_CAP)
(gdb) next
3728                    kbd_led_status &= ~LED_CAP;
(gdb) next
3729                    inputdevice_do_keyboard(AK_CAPSLOCK, 0);
(gdb) next
3731            ioctl(0, KDSETLED, kbd_led_status);
(gdb) next
3764            real_main(argc, argv);
(gdb) next

Thread 1 "amiberry" received signal SIGSEGV, Segmentation fault.
__strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:41
41      ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S: No such file or directory.
(gdb)

TIA

[midwan]

I cannot recreate this here:

Tested on Ubuntu and Manjaro Linux x86-64.
And it works on the ARM/ARM64 versions as well, of course (RetroPie uses this feature quite extensively)

[giantclambake]

Hmmm....interesting ....which Ubuntu release was that? I can install locally on same hardware and compare

[giantclambake]

TBH, I really DO expect my LFS builds to do the unexpected, and I likely wouldn't be here typing if that were only the case, but when I see the (stock, nothing special) Debian 10.13 doing the same thing, I have to wonder if the issue is related (segmentation fault share common ground)...

Firstly FTR ~ a fresh install of Debian 11.6, add dependencies as per amiberry github build instructions, git clone the amiberry tree and issue 'make PLATFORM=x86-64' , download AddamsFamily_v1.3_0419.lha and copy required kickstart roms into place, launch amiberry with ' ./amiberry --autoload AddamsFamily_v1.3_0419.lha ' ....works as expected.

To recreate the issue appears to be trivial for me;

Fresh install of Debian 10.13 (using --> https://gemmei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/archive/10.13.0+nonfree/amd64/iso-cd/firmware-10.13.0-amd64-netinst.iso) Normal install, just XFCE4 as WM (nothing else, no gnome etc), ssh server and general system utilities.

Start fresh system, install required tools & dependencies as per amiberry github build instructions, git clone the amiberry tree and issue 'make PLATFORM=x86-64' , download AddamsFamily_v1.3_0419.lha and copy required kickstart roms into place, and launch amiberry with ./amiberry --autoload AddamsFamily_v1.3_0419.lha ....segmentation fault.

[note: regarding github page the debian target for binary libserialport is "libserialport0" not "libserialport" ]

[giantclambake]

//...can't believe I just found this.... you can recreate this by following on with the example above.

layout:

You've downloaded and compiled amiberry from git-master, so $HOMEDIR contains ~/amiberry

Copy AddamsFamily_v1.3_0419.lha to ~/amiberry/AddamsFamily_v1.3_0419.lha

Also have a copy of AddamsFamily_v1.3_0419.lha in $HOMEDIR ...ie; ~/AddamsFamily_v1.3_0419.lha

cd amiberry

./amiberry --autoload AddamsFamily_v1.3_0419.lha --> seg_fault

./amiberry --autoload ./AddamsFamily_v1.3_0419.lha --> game starts and runs

./amiberry --autoload ../AddamsFamily_v1.3_0419.lha --> game starts and runs

mkdir ~/amiberry/lha
mv AddamsFamily_v1.3_0419.lha ~/amiberry/lha/

./amiberry --autoload lha/AddamsFamily_v1.3_0419.lha --> game starts and runs

I only twigged this after seeing you'd done the same thing. I checked all this on the Debian 10.13 instance, and then recreated same (with same results) on my LFS 11.0 builds.

Question is, why is it so? It almost seems like amiberry has no fix on where cwd is?....weird.

I mean to say, it shouldn't need an explicit path to the whdload.lha file -- this is problematic when I try to create a default action for a downloaded whdload.lha file...ie; default action would be amiberry --autoload %f

Any fix for this?

TIA

[giantclambake]

Command: valgrind -s amiberry.dbg --autoload AddamsFamily_v1.3_0419.lha

==2288== Invalid read of size 1
==2288== at 0x5359FDD: strstr (vg_replace_strmem.c:1790)
==2288== by 0x568973: whdload_auto_prefs(uae_prefs*, char*) (amiberry_whdbooter.cpp:1291)
==2288== by 0x3D3B89: parse_cmdline(int, char**) (main.cpp:964)
==2288== by 0x3D42E0: parse_cmdline_and_init_file(int, char**) (main.cpp:1059)
==2288== by 0x3D4BE8: real_main2(int, char**) (main.cpp:1237)
==2288== by 0x3D4F9B: real_main(int, char**) (main.cpp:1361)
==2288== by 0x542985: main (amiberry.cpp:3764)
==2288== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2288==
==2288==
==2288== Process terminating with default action of signal 11 (SIGSEGV)
==2288== Access not within mapped region at address 0x0
==2288== at 0x5359FDD: strstr (vg_replace_strmem.c:1790)
==2288== by 0x568973: whdload_auto_prefs(uae_prefs*, char*) (amiberry_whdbooter.cpp:1291)
==2288== by 0x3D3B89: parse_cmdline(int, char**) (main.cpp:964)
==2288== by 0x3D42E0: parse_cmdline_and_init_file(int, char**) (main.cpp:1059)
==2288== by 0x3D4BE8: real_main2(int, char**) (main.cpp:1237)
==2288== by 0x3D4F9B: real_main(int, char**) (main.cpp:1361)
==2288== by 0x542985: main (amiberry.cpp:3764)

Note: LFS 11.3-x86-64 ; 'amiberry.dbg' is compiled with DEBUG=1 (git-master amiberry 5.6.1)

[midwan]

@giantclambake
This was a bug after all - thanks to your details above, I managed to narrow it down and fix it.