Local binary linux wasmvm panic

[TxCorpi0x]

Description

This pull request refactors and simplifies the logic for setting up the musl toolchain when building for Linux platforms in build/tx-chain/build.go. The most important change is the introduction of a new helper struct and function to encapsulate the configuration for musl-based toolchains, reducing code duplication and improving maintainability. The main build logic is updated to use this new abstraction.

Refactoring and toolchain configuration:

• Introduced a new linuxMuslToolchain struct and the linuxMuslToolchainFor function to encapsulate all musl toolchain paths and configuration for different Linux architectures, replacing duplicated logic and hardcoded values.
• Updated the buildTXdInDocker function to use the new linuxMuslToolchain abstraction, greatly simplifying the logic for setting up compiler and library paths, Docker volumes, and environment variables for musl-based static builds.

Build logic improvements:

• Improved comments and error handling to clarify why musl and static linking are required for Docker builds, and to ensure unsupported platforms are handled gracefully.

FIXES

Incompatible build wasm causes SIGABORT panics in wasmvm when the blockchain node is built without the needed muslc flags and properties which is needed in the Alpine blockchain node.

SIGABRT: abort
PC=0x3c12e88 m=135 sigcode=18446744073709551610
signal arrived during cgo execution

goroutine 631797 gp=0x4002d4e8c0 m=135 mp=0x4008bff808 [syscall]:
runtime.cgocall(0x34ca220, 0x401168ed98)
	runtime/cgocall.go:167 +0x44 fp=0x401168ed60 sp=0x401168ed20 pc=0x4a4134
github.com/CosmWasm/wasmvm/v2/internal/api._C2func_execute(0xffff56f75040, {0x0, 0x400f3031c0, 0x20}, {0x0, 0x4001ad3d40, 0xc8}, {0x0, 0x400da028c0, 0x46}, ...)
	_cgo_gotypes.go:318 +0x40 fp=0x401168ed90 sp=0x401168ed60 pc=0x26478d0
github.com/CosmWasm/wasmvm/v2/internal/api.Execute.func1(...)
	github.com/CosmWasm/wasmvm/v2@v2.2.4/internal/api/lib.go:291
github.com/CosmWasm/wasmvm/v2/internal/api.Execute({0xffff56f75040?, {0x4005bc9260?}}, {0x400f3031c0?, 0x401168f198?, 0x44288c?}, {0x4001ad3d40?, 0x64?, 0x401168f1f8?}, {0x400da028c0?, 0x0?, ...}, ...)
	github.com/CosmWasm/wasmvm/v2@v2.2.4/internal/api/lib.go:291 +0x52c fp=0x401168f130 sp=0x401168ed90 pc=0x264e10c
github.com/CosmWasm/wasmvm/v2.(*VM).Execute(0x4001912f30, {0x400f3031c0, 0x20, 0x20}, {{0x117, 0x1895452cac60602b, {0xfffffcfa2e8d, 0xf}}, 0x400dc24278, {{0x400a5ce910, ...}}}, ...)
	github.com/CosmWasm/wasmvm/v2@v2.2.4/lib_libwasmvm.go:214 +0x1e8 fp=0x401168f260 sp=0x401168f130 pc=0x26574f8
github.com/CosmWasm/wasmd/x/wasm/keeper.Keeper.execute({{0x50e1940, 0x40019a5af0}, {0x5193008, 0x4002f945b0}, {0x5116f30, 0x4005211880}, {0x50e1520, 0x4003033930}, {0x5195fa0, 0x4001912f30}, ...}, ...)

Reviewers checklist:

• Try to write more meaningful comments with clear actions to be taken.
• Nit-picking should be unblocking. Focus on core issues.

Authors checklist

• Provide a concise and meaningful description
• Review the code yourself first, before making the PR.
• Annotate your PR in places that require explanation.
• Think and try to split the PR to smaller PR if it is big.

---

This change is 

[miladz68]

@miladz68 reviewed 1 file and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on masihyeganeh, metalarm10, and ysv).

[masihyeganeh]

@masihyeganeh reviewed 1 file and all commit messages, and made 2 comments.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on metalarm10, TxCorpi0x, and ysv).

---

build/tx-chain/build.go line 217 at r1 (raw file):

// targetPlatform is used for all Path() lookups so local and in-Docker builds use the same toolchain.
func linuxMuslToolchainFor(targetPlatform txcrusttools.TargetPlatform) (linuxMuslToolchain, error) {
	switch targetPlatform {

This is already checked:

targetPlatform.OS == txcrusttools.OSLinux

So, I think this part is not needed.

---

build/tx-chain/build.go line 229 at r1 (raw file):

	switch targetPlatform.Arch {
	case txcrusttools.ArchAMD64:
		gccBin, wasmLib, wasmSubdir = "bin/x86_64-linux-musl-gcc", "lib/libwasmvm_muslc.x86_64.a", "/x86_64-linux-musl/lib/libwasmvm_muslc.x86_64.a"

Again, everything except x86_64 and aarch64 are duplicated. We can simply get the architecture in a variable and format those paths

[TxCorpi0x]

@TxCorpi0x made 2 comments.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on masihyeganeh, metalarm10, and ysv).

---

build/tx-chain/build.go line 217 at r1 (raw file):

Previously, masihyeganeh (Masih Yeganeh) wrote…

This is already checked:

targetPlatform.OS == txcrusttools.OSLinux

So, I think this part is not needed.

Done.

---

build/tx-chain/build.go line 229 at r1 (raw file):

Previously, masihyeganeh (Masih Yeganeh) wrote…

Again, everything except x86_64 and aarch64 are duplicated. We can simply get the architecture in a variable and format those paths

Done.

[masihyeganeh]

@masihyeganeh reviewed 1 file and all commit messages, and resolved 2 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on metalarm10 and ysv).

[ysv]

@ysv reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on metalarm10 and TxCorpi0x).

---

build/tx-chain/build.go line 264 at r2 (raw file):

	case txcrusttools.OSLinux:
		// Linux builds must use muslc + static linking so the binary runs in Alpine (txd Docker image).
		// Using glibc or dynamic wasmvm leads to SIGABRT in wasmvm/cgo when the binary runs in-container.

But SIGABRT only happens under specific circumstances right ?
Like high-load etc ?

Because it is a bit strange compilation bug fails only under high-load

[TxCorpi0x]

@TxCorpi0x made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on metalarm10 and ysv).

---

build/tx-chain/build.go line 264 at r2 (raw file):

Previously, ysv (Yaroslav Savchuk) wrote…

But SIGABRT only happens under specific circumstances right ?
Like high-load etc ?

Because it is a bit strange compilation bug fails only under high-load

The issue comes up in CI since when we usle local built binary instead of docker-built binary. this fix the issue related to txd binary which will be transferred to the container which is built using muslc.

[ysv]

@ysv resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on metalarm10).

[miladz68]

@miladz68 reviewed 1 file and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on metalarm10).