Arch Linux User Repository

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"?

@m4rn

I had the same problem. I noticed that in /etc/makepkg.conf there was the -mno-omit-leaf-frame-pointer option included in CFLAGS. I removed this, then got a different error for undefined -mno-omit-frame-pointer-march=x86-64. The corresponding option -mno-omit-frame-pointer was also in the makepkg settings, so I removed it. I ended up with yet another error, with the -march=x86-64 option enabled in the build. I ended up removing the following options, then was able to build successfully:

-fstack-clash-protection
-fcf-protection
-fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer

@m4rn

Sounds like you have something abnormal with your setup. This package builds normally for many people and especially in the chroot. Also, changing from the += to ="$CFLAGS will have a meaningful change. TL;DR, you have an issue with your setup.