Segfault when running a static binary built on Alpine musl

[j8r]

I use a library I made, clicr library, which consists of recursive macros.
When compiling this program statically with crystal build --static cli.cr in an alpine:latest, running ./cli ver give this result:

Invalid memory access (signal 11) at address 0x0
[1]    21902 segmentation fault (core dumped)  ./cli

Code:

require "clicr"
def run
  Clicr.create(
    commands: {
      ver: {
        info:   "Version with general system information",
        action: "version",
      },
    }
  )
end

def version
  puts 0.1
end

run

In gdb, when run and then backtrace, I got:

Program received signal SIGBUS, Bus error.
0x00007ffff7f4d428 in GC_find_limit_with_bound ()
(gdb) backtrace
#0  0x00007ffff7f4d428 in GC_find_limit_with_bound ()
#1  0x00007ffff7f4d4eb in GC_init_linux_data_start ()
#2  0x00007ffff7f4c521 in GC_init ()
#3  0x00007ffff7f09770 in init () at /usr/lib/crystal/core/gc/boehm.cr:88
#4  0x00007ffff7f456eb in main () at /usr/lib/crystal/core/crystal/main.cr:35
#5  0x00007ffff7ef1996 in main () at /usr/lib/crystal/core/crystal/main.cr:106

Building the code with dynamic linking works - crystal build cli.cr && ./cli ver returns 0.1

Crystal version:

/ # crystal -v
Crystal 0.26.1 (2018-08-30)

LLVM: 5.0.1
Default target: x86_64-alpine-linux-musl

[RX14]

looks like a bdwgc bug

[RX14]

actually, that gdb SIGBUS is expected, you should keep using continue when you get a SIGBUS inside GC_find_limit* until you get to the real segfault

[j8r]

Thanks @RX14 , after continuing:

Continuing.
[New LWP 22454]
[New LWP 22455]
[New LWP 22456]

Thread 1 "cli" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()

[RX14]

useful...

[ysbaddaden]

Sounds a lot like #4276

[j8r]

Compiling with crystal build --link-flags "-static -lunwind" seems to do the trick...

[j8r]

Reduced example:

raise ""

Invalid memory access (signal 11) at address 0x0
[1]    1481 segmentation fault (core dumped)  ./bin

Duplicate of #4276

[RX14]

@j8r does --static --link-flags=-lunwind fix it? If those link flags fix the issue I think we can fix it for everyone

[j8r]

I've followed @ysbaddaden 's suggestion. The backtrace is empty, but at least the static linking procudes a working binary.

[rdp]

Maybe https://www.openwall.com/lists/musl/2020/10/29/21 ?