Segmentation fault during LibGC.init

[chances]

Working on my bismuth graphics library, I'm encountering a segfault traced to Crystal's GC initialization:

GC_find_limit_with_bound (@GC_find_limit_with_bound:34)
GC_init_linux_data_start (@GC_init_linux_data_start:13)
GC_init (@GC_init:239)
init (/usr/share/crystal/src/gc/boehm.cr:127)
main (/usr/share/crystal/src/crystal/main.cr:35)
main (/usr/share/crystal/src/crystal/main.cr:119)
__libc_start_main (@__libc_start_main:64)
_start (@_start:15)

Crystal version:

Crystal 1.2.2 [6529d725a] (2021-11-10)

LLVM: 10.0.0
Default target: x86_64-unknown-linux-gnu

OS: elementary OS 6.1 - Ubuntu 20.04.1 - Linux 5.11.0-41-generic x86_64

Reproduction Instructions

1. Clone chances/bismuth and checkout the linux-crystal-sigsegv branch
2. make bin/triangle

3. LD_LIBRARY_PATH="`pwd`/lib/wgpu/bin/libs" ./bin/triangle

[beta-ziliani]

@chances to help us a bit, can you describe more what you tried? Does it happen only in Linux? Thanks.

[chances]

I'm debugging the triangle example with the CodeLLDB extension in VS Code using my Debug Triangle launch configuration.

I have not experienced this issue on my mac OS machine.

[rdp]

Does it crash? maybe #4276 (comment) ?

[chances]

No, the app does not crash when I continue program execution.

If this is expected behavior, I'd prefer to have been informed somehow beforehand, without needing to know eccentricities of Crystal's GC implementation. Perhaps in a "Debugging" section in the Getting Started docs?

[straight-shoota]

I can't reproduce this error with the given details on my system.

Instead, I get this:

$ RUST_BACKTRACE=full LD_LIBRARY_PATH="`pwd`/lib/wgpu/bin/libs" ./bin/triangle
Created main window
Created native graphics surface
Requesting graphics adapter…
thread '<unnamed>' panicked at 'Unable to request adapter: NotFound', src/device.rs:40:10
stack backtrace:
   0:     0x7fab7410d000 - std::backtrace_rs::backtrace::libunwind::trace::h34055254b57d8e79
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x7fab7410d000 - std::backtrace_rs::backtrace::trace_unsynchronized::h8f1e3fbd9afff6ec
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x7fab7410d000 - std::sys_common::backtrace::_print_fmt::h3a99a796b770c360
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x7fab7410d000 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h32d1f94a80615d18
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x7fab7412d61c - core::fmt::write::h306731c068f7162c
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/fmt/mod.rs:1110:17
   5:     0x7fab7410b525 - std::io::Write::write_fmt::hd2fa90334eee2a21
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/io/mod.rs:1588:15
   6:     0x7fab7410ea7b - std::sys_common::backtrace::_print::h5abaa2601a852287
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x7fab7410ea7b - std::sys_common::backtrace::print::h8d81445442bb638f
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x7fab7410ea7b - std::panicking::default_hook::{{closure}}::hcfe804496a9fa747
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:208:50
   9:     0x7fab7410e551 - std::panicking::default_hook::hbea8e3ccf2ba8901
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:225:9
  10:     0x7fab7410f144 - std::panicking::rust_panic_with_hook::h7ee9e1a2d0f8975a
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:622:17
  11:     0x7fab7410ec27 - std::panicking::begin_panic_handler::{{closure}}::h8ab3b4491718b2c7
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:519:13
  12:     0x7fab7410d4fc - std::sys_common::backtrace::__rust_end_short_backtrace::hd489062ffa586a9f
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x7fab7410eb89 - rust_begin_unwind
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
  14:     0x7fab737cbf51 - core::panicking::panic_fmt::hca6330e3e14086b4
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
  15:     0x7fab737cc043 - core::result::unwrap_failed::h6160d2b4bfbb0e87
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1355:5
  16:     0x7fab7394b893 - core::result::Result<T,E>::expect::ha288d7169dfbf190
                               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:997:23
  17:     0x7fab738acb60 - wgpuInstanceRequestAdapter
                               at /tmp/wgpu-native/src/device.rs:32:14
  18:           0x513592 - request
                               at /home/johannes/Projects/chances/bismuth/lib/wgpu/src/wgpu.cr:209:7
  19:           0x5108fc - initialize
                               at /home/johannes/Projects/chances/bismuth/src/bismuth.cr:37:16
  20:           0x5106f8 - initialize
                               at /home/johannes/Projects/chances/bismuth/examples/triangle.cr:20:5
  21:           0x5106c9 - new
                               at /home/johannes/Projects/chances/bismuth/examples/triangle.cr:19:3
  22:           0x467d89 - __crystal_main
                               at /home/johannes/Projects/chances/bismuth/examples/triangle.cr:101:1
  23:           0x529de6 - main_user_code
                               at /home/linuxbrew/.linuxbrew/Cellar/crystal/1.2.2/src/crystal/main.cr:110:5
  24:           0x529c5c - main
                               at /home/linuxbrew/.linuxbrew/Cellar/crystal/1.2.2/src/crystal/main.cr:96:7
  25:           0x473ca6 - main
                               at /home/linuxbrew/.linuxbrew/Cellar/crystal/1.2.2/src/crystal/main.cr:119:3
  26:     0x7fab72bda0b3 - __libc_start_main
  27:           0x4677de - _start
  28:                0x0 - <unknown>
Triangle app exited

[rdp]

I did run into this just running a normal app through gdb today. Yeah a warning might be nice, PR for the docs welcome!

[straight-shoota]

I don't follow. What should be a warning about? So far, I don't see any understanding about what this is even about.

[rdp]

When you run a crystal app in gdb, it pauses on a "confusing" segfault initially...

[straight-shoota]

Wait, what does this have to do with gdb? Does the error only reproduce with gdb and not without? The OP says nothing about a debugger being involved.
And what do you mean by "initially"? Does the behaviour change?

[beta-ziliani]

I'm debugging the triangle example with the CodeLLDB extension in VS Code using my Debug Triangle launch configuration.

I guess it's an issue only with debugging?

[rdp]

I thnk so, not much can be done besides maybe documenting it somewhere?

[HertzDevil]

This is intended behaviour: https://hboehm.info/gc/debugging.html

It probably does not depend on the debugger being used; a quick search suggests this is not exclusive to Crystal either. So it is generally safe to ignore SIGSEGV on startup and handle it again after __crystal_main. For LLDB this is:

breakpoint set -n main -G true -o true -C 'process handle -s false -n false SIGSEGV SIGBUS'
breakpoint set -n __crystal_main -G true -o true -C 'process handle -s true -n true SIGSEGV SIGBUS'

[beta-ziliani]

Can we close this now that #12119 is merged?