Arch Linux User Repository

Some try and errors later. Something is wired. After leaving the app I can only login after. rm -rf .cache/Minecraft\ Linux\ Launcher .config/Minecraft\ Linux\ Launcher .config/QtProject* && mkdir .config/QtProject and doing the full re-login again.

And inside Minecraft I am not able to login to my M$ Account. Just an infinite window waiting for whatever.

Perhaps worth to mention here. I got a lot of "Speicherabzugsfehler" when trying to run. No chance to run Minecraft again.

After some digging I got it working again by creating a missing (empty) Directory: mkdir -p ${HOME}/.config/QtProject

After this I could start mcpe again (and play the game).

I've tried building and running in two different systems and I get the same buffer overflow error:

19:44:06 Info  [Launcher] Version: client 89d4f5c / manifest cfb5ca5
19:44:06 Info  [Launcher] OS: Linux
19:44:06 Info  [Launcher] Arch: x86_64
19:44:06 Info  [Launcher] CPU: AuthenticAMD AMD Ryzen 5 5600X 6-Core Processor             
19:44:06 Info  [Launcher] CPU supports SSSE3: YES
19:44:06 Info  [Launcher] Reading Launcher Settings File: /home/dimitris/.local/share/mcpelauncher/mcpelauncher-client-settings.txt
19:44:06 Info  [Launcher] Applied Launcher Settings
19:44:06 Trace [Launcher] Loading android libraries
19:44:06 Trace [Launcher] linker loaded
19:44:06 Trace [REDIRECT] /data/data/com.mojang.minecraftpe to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data/usr/proc/52722/cmdline to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data/mcpelauncher-client to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] . to /home/dimitris/.local/share/mcpelauncher/versions/1.21.92.1/assets/
19:44:06 Trace [LinkerUtils] Loaded OS library libm.so.6
19:44:06 Trace [LinkerUtils] Loaded OS library libz.so.1
*** buffer overflow detected ***: terminated
Signal 6 received
Backtrace elements: 17
# 0 mcpelauncher-client(+0x40bea9) [0x557440fdaea9]
# 1 /usr/lib/libc.so.6(+0x3def0) [0x7f29d1a4def0]
# 2 /usr/lib/libc.so.6(+0x9774c) [0x7f29d1aa774c]
# 3 /usr/lib/libc.so.6(gsignal+0x20) [0x7f29d1a4ddc0]
# 4 /usr/lib/libc.so.6(abort+0x26) [0x7f29d1a3557a]
# 5 /usr/lib/libc.so.6(+0x265c9) [0x7f29d1a365c9]
# 6 /usr/lib/libc.so.6(+0x124a09) [0x7f29d1b34a09]
# 7 /usr/lib/libc.so.6(+0x124374) [0x7f29d1b34374]
# 8 /usr/lib/libc.so.6(+0x125b1b) [0x7f29d1b35b1b]
# 9 mcpelauncher-client(+0x4cfeaf) [0x55744109eeaf]
# 10 mcpelauncher-client(+0x4cfd3f) [0x55744109ed3f]
# 11 mcpelauncher-client(+0x4c8578) [0x557441097578]
# 12 mcpelauncher-client(+0x4c6bc7) [0x557441095bc7]
# 13 mcpelauncher-client(+0x1719e7) [0x557440d409e7]
# 14 /usr/lib/libc.so.6(+0x276b5) [0x7f29d1a376b5]
# 15 /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f29d1a37769]
# 16 mcpelauncher-client(+0x16bb25) [0x557440d3ab25]
Dumping stack...
program failed with unix signal number: 6

any ideas?

Not a problem :)

@HurricanePootis Thank you kindly for the swift response and explanation! Problem has been resolved :)

@Atronin, that is an issue with how paru handles packages that use a git source. To your /etc/paru.conf, to IgnoreDevel and IgnoreDevelSource, add my package. This is because paru thinks that a PKGBUILD using a git repo as the primary source is a -git package, it uses the rebuild function. However, this is not true.

There's an issue with this package that causes the AUR helper paru to constantly ping it as outdated, saying that the new version is "latest-commit" (instead of the usual numerical format), proceeding with a pointless reinstall that helps the notification go away until the next reboot. Then the process repeats - and of course, the package always stays at 1.3.0-2.

This issue does not appear with the AUR helper yay, but can be replicated across different devices. It's the only one across over 30 AUR packages I use to have this problem.

Can anything be done to resolve it?

Nice catch, @gwuensch. Looks like the PKGBUILD should be modified as:

        CFLAGS+=" -flto=thin"
        LDFLAGS+=" -fuse-ld=lld"

or, alternatively:

        CFLAGS="$CFLAGS -flto=thin"
        LDFLAGS="$LDFLAGS -fuse-ld=lld"

CFLAGS+="$CFLAGS ..." is definitely the cause of this error. The system-wide CFLAGS (as set in makepkg.conf) are included twice, once because the variable is appended to (+=), and another time because the existing variable ($CFLAGS) is expanded in the new variable's value. I don't know why this would be any different in a clean chroot.

In this case, appending without an additional whitespace corrupts the CFLAGS: The last argument (-fno-omit-frame-pointer) and the first argument (-march=x86-64) essentially are combined into -mno-omit-leaf-frame-pointer-march=x86-64. For the LDFLAGS, -Wl,-z,pack-relative-relocs and -Wl,-O1 become -Wl,-z,pack-relative-relocs-Wl,-O1, though that does not seem to cause an error.

@HurricanePootis

Thanks man. Apparently setting +="$CFLAGS" to ="$CFLAGS" solves my issues.

Why don't they just update the aur PKGBUILD to not use +="$CFLAGS"?