amiberry on CachyOS (Arch Linux) buffer overflow

[ut316ab]

I haven't put this in issues because I think this is something i'm getting wrong and not a problem with the code.

When I first installed CachyOS, I installed Amikit, and used the amiberry compiled for Debian Bookworm. It worked fine. Then I rebooted and now everytime I try to launch amiberry is says buffer overflow detected and core dumps.

I then compiled it myself and and it would do the same thing on the one I compiled.

However, if I run amiberry as root, it works fine. That makes me think that somehow amiberry is trying to write to a directory my user doesn't have permissions too?

Has anyone seen this behavior or know what I might be doing wrong?

I think maybe it's wayland related?

I just ran it with SDL_VIDEODRIVER=x11 amiberry and it works

[midwan]

Which version of Amiberry are we talking about?
Try running it from the console, to see if any errors show up there.
Also, enable logging and check the logfile for any errors as well.

Wayland works fine normally, but there is an SDL2 issue that can be bypassed with a certain setting. Check the wiki here: https://github.com/BlitterStudio/amiberry/wiki/FAQ#q-on-debian-bookworm-the-performance-when-running-in-full-window-is-terrible-but-its-much-faster-in-windowed-mode-what-is-going-on

[giantclambake]

@midwan ~ ...just now looking at that FAQ entry, it brought back memories of a discussion had in the LFS camp about 20years ago. The polemical argument was about providing 'instruction', versus the use of 'instructions' ...

*That FAQ entry uses instructions ~ how to open the nano editor in root mode ; having to provide passwd if prompted ; the respective lines of text to enter into the editor window (can be c&p) ; how to command nano into 'operations' mode ; how to actually save the file & exit nano....

There is nothing 'wrong' with that approach ~ in fact from a learning/teaching perspective, it is likely the 'right' way to go about it, however in practice such can very much 'fall on its face', due to one facet --- human fallibility ; it is far to easy to introduce typos.

What we found was folks can copy-to-buffer/paste far more accurately than manually entering text in a console/xterm ;) In as much as learning/teaching stands to lose it's purchase here, for the sake of 'correct' results, the resolve was to put all 'critical' text entry into the copy-to-buffer field, and provide instruction to folks of 'what to do next'....ie; for the example here...

*Open a console/xterm and paste the following command and hit Enter (then providing your password if required)

sudo cat > /etc/profile.d/sdl2_fix.sh << "EOF"
#!/bin/bash
export SDL_VIDEODRIVER=kmsdrm,wayland,x11
EOF

*Log out and log back in, for the changes to take effect.

If one can for a moment put themselves into the shoes of a user, who just wants to use amiberry, faces this problem, and just wants an easy cut&paste fix (and never wants to nor will ever use nano in the future)....which approach best appeals here, and will most likely result in a positive outcome (for the user).... instructions? Or instruction?

....my money is on the latter 8)

/2cents

Note: that FAQ entry is 'dangling' somewhere between mentioning debian at the outset, but closing with reference to raspi-config, which makes me question if this is an RPi specific thing....it might make some question if it applies to debian desktop on other platforms...

[ut316ab]

This is what happens:

~/amikit/Amiberry
❯ echo $SDL_VIDEODRIVER
kmsdrm,wayland,x11

~/amikit/Amiberry
❯ ./amiberry
*** buffer overflow detected ***: terminated
fish: Job 1, './amiberry' terminated by signal SIGABRT (Abort)

Not much in the log:

❯ tail amiberry.log
Amiberry v6.3.4 preview (2024-09-01) Logfile

Compiled against SDL2 v2.26.5, Linked against SDL2 v2.30.9

Now the odd part:
❯ export SDL_VIDEODRIVER=x11

~/amikit/Amiberry
❯ ./amiberry

~/amikit/Amiberry
❯

It works if I set SDL_VIDEODRIVER to just x11

What made me try this to begin with is I compiled it with Debug Mode, and then I threw the coredump in gdb.

First I cloned the preview build and built it with Debug like the instructions said:

~/git/amiberry/build preview
❯ ./amiberry --version
Amiberry 7.0.0
Copyright (C) 2016-2024 Dimitris Panokostas

~/git/amiberry/build preview
❯ export SDL_VIDEODRIVER=kmsdrm,wayland,x11

Still same problem with SDL_VIDEODRIVER set
~/git/amiberry/build preview
❯ ./amiberry
*** buffer overflow detected ***: terminated
fish: Job 1, './amiberry' terminated by signal SIGABRT (Abort)

So I threw it in gdb:
~/git/amiberry/build preview
❯ cp /var/lib/systemd/coredump/core.amiberry.1000.911411a45a524e3db5fda8b9593929c2.48751.1732416255000000.zst ./

~/git/amiberry/build preview
❯ zstd --decompress core.amiberry.1000.911411a45a524e3db5fda8b9593929c2.48751.1732416255000000.zst
core.amiberry.1000.911411a45a524e3db5fda8b9593929c2.48751.1732416255000000.zst: 78479360 bytes

GNU gdb (GDB) 15.2
Copyright (C) 2024 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 "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://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 ./amiberry...
[New LWP 48751]
[New LWP 48752]

This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.archlinux.org
https://debuginfod.cachyos.org
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `./amiberry'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007c77879dc3db in pthread_kill () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7c77877f34c0 (LWP 48751))]
(gdb) bt
#0 0x00007c77879dc3db in pthread_kill () from /usr/lib/libc.so.6
#1 0x00007c778797d9d8 in raise () from /usr/lib/libc.so.6
#2 0x00007c778796047b in abort () from /usr/lib/libc.so.6
#3 0x00007c7787961508 in ?? () from /usr/lib/libc.so.6
#4 0x00007c7787a690fb in __fortify_fail () from /usr/lib/libc.so.6
#5 0x00007c7787a68a86 in __chk_fail () from /usr/lib/libc.so.6
#6 0x00007c7787a6a449 in __strlcpy_chk () from /usr/lib/libc.so.6
#7 0x00007c7788196809 in ?? () from /usr/lib/libSDL2-2.0.so.0
#8 0x00007c778819763a in ?? () from /usr/lib/libSDL2-2.0.so.0
#9 0x00007c778814528b in ?? () from /usr/lib/libSDL2-2.0.so.0
#10 0x00007c77880203e1 in ?? () from /usr/lib/libSDL2-2.0.so.0
#11 0x00000000006c0442 in main (argc=, argv=0x7fff1a742eb8) at /home/darryl/git/amiberry/src/osdep/amiberry.cpp:4506
(gdb) frame 11
#11 0x00000000006c0442 in main (argc=, argv=0x7fff1a742eb8) at /home/darryl/git/amiberry/src/osdep/amiberry.cpp:4506
4506 if (SDL_Init(SDL_INIT_EVERYTHING) != 0)
(gdb) list
4501
4502 if (!init_mmtimer())
4503 return 0;
4504 uae_time_calibrate();
4505
4506 if (SDL_Init(SDL_INIT_EVERYTHING) != 0)
4507 {
4508 write_log("SDL could not initialize! SDL_Error: %s\n", SDL_GetError());
4509 abort();
4510 }

I'm not really a programmer though so this could be just digging into stuff I don't fully understand.

I think I narrowed it down to the specific problem though:

~/git/amiberry/build preview 3m 25s
❯ export SDL_VIDEODRIVER=wayland,x11

~/git/amiberry/build preview
❯ ./amiberry

So what is causing the buffer overflow for me is the kmsdrm part.

I have an AMD Radeon RX 5700 XT, i'm wondering if that kmsdrm part is nvidia specific?

[solskogen]

I have an AMD Radeon RX 5700 XT, i'm wondering if that kmsdrm part is nvidia specific?

It is not. But I've seen the same thing happen sometimes on my Arch installation as well, and for some strange reason it helps to run sync before running amiberry.

[giantclambake]

It is not. But I've seen the same thing happen sometimes on my Arch installation as well, and for some strange reason it helps to run sync before running amiberry.

That'd be odd in and of itself ... as kmsdrm is largely kernel bound ;) The other 'daft' observation would be, if one is in a x11/wayland windowed environment, I doubt kmsdrm is even an issue?...ie; you're bound to be using the SDL x11/wayland backends anyway....ie; the fact SDL is (apparently) failing to initialize when the kmsdrm env_var is present, shouldn't be happening, (because) the process isn't running in a console --- the fact it does work when run as root, suggests to me the console layer is unavailable to $user when a x11/wayland session is running?

Meh...only way to look at this, is to install CachyOS here, and have a look at how it's staged...shouldn't take long //famous last words...

[giantclambake]

@ut316ab -- cannot recreate this issue here .... steps taken;

*Fresh installation of CacheyOS current, in XFCE4 flavor, onto x86-64 platform (HP Elitedesk 800 G1)
*Log in, open browser, navigate to https://github.com/BlitterStudio/amiberry/wiki/Compile-from-source
*Open an xterm, cd //ensure you're in your home directory
*As this is an Arch based distro, install required dependencies with....
sudo pacman -S base-devel cmake sdl2 sdl2_ttf sdl2_image flac mpg123 libmpeg2 libserialport portmidi enet

//note: git & ninja should perhaps be part of that commandline...definitely git..?

*git clone https://github.com/BlitterStudio/amiberry && cd amiberry
*
*I'm aiming for a system-wide install, to compile.. cmake -B build -G Ninja -DCMAKE_INSTALL_PREFIX=/usr && cmake --build build
*I can test the compiled binary in place...ie; invoke build/amiberry --- result; amiberry starts & runs as expected
*Now I can install the build system-wide with... sudo cmake --install build --prefix /usr

//note: seems there's a need to issue sudo update-desktop-database & sudo update-mime-database /usr/share/mime on this //distro, along with updating manpath cache etc...

Now I can just issue amiberry at the commandline (or use desktop launcher menu), and amiberry works as expected.

Note: the env_var SDL_VIDEODRIVER is unset/unused

I've listed the steps, hopeful you might spot something that I'm doing (which works), versus what you're doing there...

I don't have AmiKit installed, but I treat that like I would say ClassicWB.... it's just using the 'stock' amiberry build, so I find it easier to move it's .hdf/directories under ~/Amiberry/harddrives/amikit12/ , and just change it's config.uae file accordingly...

...also, things like which window manager is being used can be participle...maybe you can provide some more details, that might help me recreate this with CacheyOS...but right the now, it's working as expected here 8)

[ut316ab]

That was my experience too. I use KDE Plasma 6 if that makes a difference. However, that was my experience as well. When I first installed CachyOS, I installed amikit and it worked. I rebooted, and after the reboot it started to fail. Part of the Amikit installation was to put sdl2_fix.sh in /etc/profile.d. That sdl2_fix.sh is what sets the SDL_VIDEODRIVER variable.

#!/bin/bash
export SDL_VIDEODRIVER=kmsdrm,wayland,x11

So I didn't start to get the buffer overflow until that variable was set.

[giantclambake]

You don't need this ~ the AmiKit installation has been adapted from the RPi based AmiKit setup, and there's a number of things that have been carried across that aren't applicable to other platforms ~ the sdl2_fix.sh script is another of these oversights =)

[giantclambake]

..I was able to recreate this here, simply by providing the sdl2_fix.sh script, to the stock CacheyOS environment...ergo, fix is..

sudo rm /etc/profile.d/sdl2_fix.sh //you likely need to log out, and log in again for changes to take effect

For mine, the problem starts with - https://github.com/BlitterStudio/amiberry/wiki/FAQ#q-on-debian-bookworm-the-performance-when-running-in-full-window-is-terrible-but-its-much-faster-in-windowed-mode-what-is-going-on

...specifically the words ... (Bookworm is using Wayland by default) ....that, is a generalistic misnomer. The actual situation wrt wayland support in debian, is summarized here -> https://wiki.debian.org/Wayland ....the cliff notes...

-anything listed there as 'unsupported' will very likely get x11/Xorg, not wayland

-For games, applications, or other software that uses SDL2 as a toolkit, set the SDL_VIDEODRIVER environment variable to "wayland". Note that doing this on a system-wide basis isn't recommended, as many proprietary applications use statically-linked versions of SDL2 that are older and may break when forcing the usage of Wayland. It should be noted the sdl2_fix.sh script, is applying the change system-wide, which as we read is not recommended.

-GDM (GNOME Display Manager) will automatically use Wayland when supported, except when using the proprietary NVIDIA driver, in which case it will fall back to X11 due to instability.

...I could go on, but the point is debian does not use wayland by default -- it depends on platform, and which window manager you select.... and obviously things like video driver.

...I sent an email to Jan (of AmiKit) pointing this out....it likely does apply to RPi/Raspbian, but definitely does not apply to something like CacheyOS on x86-64....he'll likely sort it out in due course ;)

HTH

[solskogen]

I've fixed the FAQ.

[giantclambake]

Thanks, that reads better ;)