Command lookup fails on Aarch64

[Gelbpunkt]

Hi, for me entering any command results in "Unknown command", for example:

Loading registries
Loading blocks
Loading vanilla datapack
Registering items
Registering blocks
Registering commands
Loading server properties
Loading whitelist
Loading world
Starting server
Done! For help, type "help"
help
Unknown command: help

Everything otherwise works fine, it's just commands that aren't working. I'm on Alpine Linux Edge with gnucobol from this MR. I've tried commits 75d8220 and e99a62b, both have broken commands for me. Otherwise everything works as expected.

The APKBUILD used for building CobolCraft is as follows (the minecraft data is bundled separately):

# Contributor: J. Neuschäfer <[email protected]>
# Maintainer: J. Neuschäfer <[email protected]>
pkgname=cobolcraft
pkgver=0.0.0_git20250105
_pkgrev=75d8220c33cfd7d77dfb583d8882cebd6671d8a6
pkgrel=0
pkgdesc="Minecraft server written in COBOL"
url="https://github.com/meyfa/CobolCraft/"
arch="all"
license="MIT"
makedepends="gnucobol gmp-dev zlib-dev"
source="https://github.com/meyfa/CobolCraft/archive/$_pkgrev/cobolcraft-$_pkgrev.tar.gz"
builddir="$srcdir/CobolCraft-$_pkgrev"

prepare() {
	sed -i -e 's#ASSIGN TO "blobs/#ASSIGN TO "/usr/share/cobolcraft/blobs/#' \
		src/packets/update-tags.cob
}

build() {
	# Note: the default target would download data from the internet and is
	# therefore avoided here.
	make cobolcraft
}

check() {
	make test
}

package() {
	install -Dm755 cobolcraft "$pkgdir"/usr/bin/cobolcraft
	install -Dm644 blobs/update_tags_packets.txt \
		"$pkgdir"/usr/share/cobolcraft/blobs/update_tags_packets.txt
}

sha512sums="
48b0857f09e572f6cce054d3f9ebd21780f3079072b35d4c0a370337174fe97e6a33760a8880a44c55d0568a51b9a9e527bf4fa7d7a7b0c69786595ba2b5b8dd  cobolcraft-75d8220c33cfd7d77dfb583d8882cebd6671d8a6.tar.gz
"

[meyfa]

I cannot reproduce this behavior, neither on Ubuntu nor within an Alpine Docker container (with GnuCOBOL 3.2 compiled from source).

The fact that the command is echoed back seemingly correctly leads me to believe there may be some invisible character(s) in the string.

Would you be able to add the following 2 lines to src/commands.cob, PROGRAM-ID. HandleCommand., immediately after PROCEDURE DIVISION ... -LENGTH. (line 59):

    CALL "EncodeHexString" USING LK-INPUT LK-INPUT-LENGTH BUFFER
    DISPLAY BUFFER(1:LK-INPUT-LENGTH * 2)

Recompile & run, enter help again and report back with the output?

[Gelbpunkt]

Hi, thanks for your reply. When I enter help I see 68656c700a which equals help\n.

[meyfa]

Thanks for checking. 68656c700a is (unfortunately) the expected output.
Could you please try it once more with #265? If that doesn't fix it, I'm out of ideas...

[GitMensch]

If that doesn't fix it, I'm out of ideas...

Hm, attaching to the server using gdb -p $(pgrep cobolcraft) possibly? :-)

[meyfa]

Hm, attaching to the server using gdb -p $(pgrep cobolcraft) possibly? :-)

That's something @Gelbpunkt would need to do, as I cannot reproduce this bug report.

[Gelbpunkt]

Thanks for checking. 68656c700a is (unfortunately) the expected output. Could you please try it once more with #265? If that doesn't fix it, I'm out of ideas...

I've just tried the latest commit again, problem still persists. Maybe this is an aarch64 issue? I haven't tried x86_64 yet

[meyfa]

I can reproduce this by passing --platform=linux/aarch64 to Docker 👍

[meyfa]

The patch in #270 fixes it for me. Without it, COMMAND-NAME(COMMAND-INDEX) displays as 0000000004 inside the PERFORM.

@GitMensch Looks like a GnuCOBOL 3.2 bug to me. I'll check 3.3-dev as well in a moment, and if you'd like I can attempt a minimal repro.

[GitMensch]

If this occurs with 3.3-dev - yes, please wrap up a reproducer. Until then I'd guess it may be a bug in the COBOL part (we can easily check where it happens with setting a watchpoint to PART-LENGTH(1) and PART-VALUE(1).

Maybe you can give that a try to get an idea why the error / where exactly it occurs? If you want and are a bit stuck we could have a 20-30 minute debug / fix session on that today.

[Gelbpunkt]

I can confirm the patch in #270 works for me as well.

[meyfa]

The following is a minimal reproductive case for the GnuCOBOL issue, visible in GC 3.2 and also 3.3-dev:

IDENTIFICATION DIVISION.
PROGRAM-ID. Main.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 COMMANDS.
    02 COMMAND OCCURS 10 TIMES.
        03 COMMAND-NAME PIC X(10).
01 PARTS.
    02 PART OCCURS 10 TIMES.
        03 PART-VALUE PIC X(10).
        03 PART-LENGTH BINARY-LONG UNSIGNED.

PROCEDURE DIVISION.
    MOVE "help" TO COMMAND-NAME(1)
    MOVE "help" to PART-VALUE(1)
    MOVE 4 TO PART-LENGTH(1)
    DISPLAY "'" COMMAND-NAME(1) "', '" PART-VALUE(1)(1:PART-LENGTH(1)) "'"
    GOBACK.

END PROGRAM Main.

Note that -debug is a requirement for it to occur:

$ cobc -x -free -debug debug.cob && ./debug
'0000000004', 'help'
$ cobc -x -free debug.cob && ./debug       
'help      ', 'help'

[meyfa]

I'm going to merge #270 as a workaround. Thanks @Gelbpunkt and especially @GitMensch for the debugging help!

@GitMensch tracked it down to different code generation between x86_64/Aarch64 due to differences in support for aligned/unaligned memory access between the platforms.

However, assuming this will be fixed in GnuCOBOL 3.3, we are bound to come across this bug again at some point as long as we keep support for 3.1 and 3.2. The better workaround would be removal of the -debug cobc flag, but that has other disadvantages.

Once GitHub Actions adds free Aarch64 runners, I will add them to the test matrix so we at least have some coverage.