Difficult to trace segfault

Help & Support
1

Hi friends,

Got a pretty whacky segfault on my hands. However once the class in included into the application, the application segfaults on an array resize deep in a seperate library.

I’ve given it my best to reduce the code required to recreate this segfault with minimal code, however the class itself compiles and runs fine independently of the application with a few changes to the requirements paths.

Removing this line leads me to believe it’s related to the initialization of the external clustering class.

Disregard the database connections. This appears to be happening before any IO.

I understand if it’s a bit of a pain to dig into this, but I thought I’d put this up here given its untraceable nature.

2

What’s the backtrace when it blows up? Error message? When run through gdb? Maybe run it in valgrind and see if it spots any failures? --release vs --debug make a difference? GL!

1 Like
3

A solution was come to, but it’s a bit of a hack…

The Clustering class accepts a Proc in the initializer. To fix the segfault, the initialize argument was removed and turned into a property which was set through a captured block through the start method.

I disabled GC pretty early in the debug process to no avail.
Tried LLDB.
--release, and --debug have both been tried independetly, also to no avail.

This is the seggy.

Invalid memory access (signal 11) at address 0x4
[0x100b6576b] *CallStack::print_backtrace:Int32 +107
[0x100b066f6] __crystal_sigfault_handler +262
[0x7fff57be2b5d] _sigtramp +29
[0x100ce15e1] *Array(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool)))@Array(T)#check_needs_resize:(Pointer(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool))) | Nil) +17
[0x100ce1566] *Array(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool)))@Array(T)#push<NamedTuple(field: Symbol, message: String, positive: Nil, negative: Nil, block: Proc(RethinkORM::Base+, Bool))>:Array(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool))) +70
[0x100ce150e] *Array(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool)))@Array(T)#<<<NamedTuple(field: Symbol, message: String, positive: Nil, negative: Nil, block: Proc(RethinkORM::Base+, Bool))>:Array(NamedTuple(field: Symbol, message: String, positive: Proc(RethinkORM::Base+, Bool) | Nil, negative: Proc(RethinkORM::Base+, Bool) | Nil, block: Proc(RethinkORM::Base+, Bool))) +94
[0x100ae868d] __crystal_main +4285
[0x100ecbe4b] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +27
[0x100ecbcdb] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +43
[0x100af80fb] main +27
4

Can you please state which compiler and stdlib version you’re using, which llvm version and on which platform?

5

kind of reminds me of https://github.com/crystal-lang/crystal/issues/8482 but maybe unrelated :)

2 Likes
6

Hi @straight-shoota, sorry I didn’t include it in my original post.

Crystal 0.33.0 (2020-02-14)

LLVM: 9.0.1
Default target: x86_64-apple-macosx