Build fails with (signal: 11, SIGSEGV: invalid memory reference)

[virtualritz]

I had previously waited for #493 to be closed as I had hoped this would fix it for my case, a libfive wrapper, too.

However, it still persists:

error: failed to run custom build command for `libfive-sys v0.1.0 (/Users/moritz/code/crates/libfive-sys)`

Caused by:
  process didn't exit successfully: `/Users/moritz/code/crates/libfive-sys/target/debug/build/libfive-sys-8ef0dc6589c9b81d/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

The repository is here.
Requires --recursive cloning.
I am building on macOS. The README has instructions for dependencies.

I am only including libfive.h in my wrapper.hpp.

Libfive uses C++17 features. The previous version I tried to wrap, in January, was just using C++11 features. I.e. I doubt this is related.

Just run cargo build on latest nightly to reproduce.

[emilio]

Is there any chance you could grab an stack trace or such with a debugger? I'm not on macOS.

[virtualritz]

Not sure how to do this in this case. After spending 20mins (!) to codesign gdb (what a PITA, Apple!), I tried:

gdb cargo
(gdb) set follow-fork-mode child
(gdb) run build
Starting program: /Users/moritz/.cargo/bin/cargo build
[New Thread 0x2403 of process 4480]
[New Thread 0x1b03 of process 4480]
[New Thread 0x1c03 of process 4480]
warning: unhandled dyld version (16)
[New Thread 0x2203 of process 4480]

Thread 4 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x2203 of process 4480]
0x0000000100f5d000 in ?? ()
(gdb) continue
Continuing.
   Compiling libfive-sys v0.1.0 (/Users/moritz/code/crates/libfive-sys)
[New Thread 0x1b0f of process 4480]====> ] 54/56: libfive-sys(build)
[New Thread 0x1d03 of process 4480]
The following warnings were emitted during compilation:

warning: "/Users/moritz/code/crates/libfive-sys/target/debug/build/libfive-sys-e5d56d354108c403/out/include"


Thread 5 received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x1b0f of process 4480]
0x00007fff68420062 in ?? ()
(gdb) continue
Continuing.
error: failed to run custom build command for `libfive-sys v0.1.0 (/Users/moritz/code/crates/libfive-sys)`

Caused by:
  process didn't exit successfully: `/Users/moritz/code/crates/libfive-sys/target/debug/build/libfive-sys-8ef0dc6589c9b81d/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
  ...
  [Inferior 1 (process 4480) exited with code 0145]
  (gdb)

I.e. I did a set follow-fork-mode child but it seems gdb stays with the parent, 4480 in this case.

Sorry about this, last time I used a debugger was probably >ten years ago. Any tips?

[virtualritz]

Never mind, I was more successful with lldb and attaching to the child. I think I got something:

Process 5740 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef400fd0)
    frame #0: 0x00000001001699f8 build-script-build`_$LT$usize$u20$as$u20$core..slice..index..SliceIndex$LT$$u5b$T$u5d$$GT$$GT$::get_unchecked::hdffe77567d886243(self=<unavailable>, slice=(data_ptr = <read memory from 0x7ffeef400ff8 failed (0 of 8 bytes read)>, length = 4751904768)) at index.rs:165
   162 	    }
   163
   164 	    #[inline]
-> 165 	    unsafe fn get_unchecked(self, slice: *const [T]) -> *const T {
   166 	        // SAFETY: the caller guarantees that `slice` is not dangling, so it
   167 	        // cannot be longer than `isize::MAX`. They also guarantee that
   168 	        // `self` is in bounds of `slice` so `self` cannot overflow an `isize`,
Target 0: (build-script-build) stopped.

[emilio]

Is there any chance of getting a backtrace? That's somewhere in the std code right? I wonder if we're overflowing the stack or such.

[virtualritz]

The above is the only thing I got in lldb. I had RUST_BACKTRACE set to full. I would need some handholding if there was some way I'm not aware of.

[virtualritz]

Is the problem not reproducible on other platforms using my repo?

[spellcard199]

Is the problem not reproducible on other platforms using my repo?

Hello. I know next to nothing about C/C++ and just the very basics about Rust so I can't really help, but I tried to compile the project on Fedora 33 and I can reproduce the issue.

These are the steps needed to avoid additional errors before the current issue on Fedora 33:

1. Install dependencies:

dnf install boost-devel cmake eigen3-devel libpng-devel libatomic clang libcxx-devel

2. Change the following lines in build.rs:

- .clang_arg("-I/usr/local/include/eigen3")
+ .clang_arg("-I/usr/include/eigen3")
- .clang_arg("-I/usr/local/include")
+ .clang_arg("-I/usr/include")

[boydjohnson]

I got the seg fault running bindgen as a binary on Ubuntu 18.04.

So with bindgen v0.58.1 built from rust-bindgen repo unoptimized:

(gdb) run wrapper.hpp -- -I /usr/include/ -I /usr/include/eigen3/ -std=c++17 -I libfive/libfive/include/

causes

Thread 1 "bindgen" received signal SIGSEGV, Segmentation fault.
0x00005555558a7ed3 in core::ptr::const_ptr::<impl *const [T]>::as_ptr (self=<error reading variable: Cannot access memory at address 0x7fffff7feff8>)

A backtrace:

(gdb) where
#0  0x00005555558a7ed3 in core::ptr::const_ptr::<impl *const [T]>::as_ptr (self=<error reading variable: Cannot access memory at address 0x7fffff7feff8>)
    at /home/boydjohnson/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/const_ptr.rs:936
#1  0x00005555559041f8 in <usize as core::slice::index::SliceIndex<[T]>>::get_unchecked (self=159730, slice=...)
    at /home/boydjohnson/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:172
#2  0x000055555590442b in <usize as core::slice::index::SliceIndex<[T]>>::get (self=159730, slice=...)
    at /home/boydjohnson/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:157
#3  0x00005555558a8667 in core::slice::<impl [T]>::get (self=..., index=159730)
    at /home/boydjohnson/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:307
#4  0x00005555557b6314 in bindgen::ir::context::BindgenContext::resolve_item_fallible (self=0x7ffffffe8798, id=...) at src/ir/context.rs:1439
#5  0x00005555557b6431 in bindgen::ir::context::BindgenContext::resolve_item (self=0x7ffffffe8798, item_id=...) at src/ir/context.rs:1447
#6  0x0000555555886944 in bindgen::ir::context::BindgenContext::resolve_type (self=0x7ffffffe8798, type_id=...) at src/ir/context.rs:1413
#7  0x00005555557c5205 in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#8  0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#9  0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#10 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#11 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#12 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#13 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#14 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#15 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#16 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#17 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#18 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#19 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#20 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#21 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#22 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#23 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#24 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#25 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#26 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#27 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#28 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#29 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#30 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#31 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#32 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#33 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#34 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#35 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#36 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#37 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#38 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#39 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#40 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#41 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#42 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#43 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#44 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#45 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#46 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366
#47 0x00005555557c524c in bindgen::ir::ty::Type::safe_canonical_type (self=0x7fffd90b78b0, ctx=0x7ffffffe8798) at src/ir/ty.rs:366

[boydjohnson]

I ran creduce on it and found a smallish code sample that causes the same issue.

This code snippet will cause unoptimized bindgen to segfault with safe_canonical_type calls being repeated in the stack trace.

enum { a };
template <typename> struct b;
template <typename, int, typename, bool, typename, bool, int, int> struct c;
template <typename d, int e, typename f, bool g, typename h, bool i, int j>
struct c<d, e, f, g, h, i, a, j> {
  typedef typename b<h>::k l;
  void m(l *);
};
template <typename d, int e, typename f, bool g, typename h, bool i, int j>
void c<d, e, f, g, h, i, a, j>::m(l *) {}

[kulp]

The segfault seems likely to be due to running out of stack. This might be the same as #1679.

[pvdrz]

enum { a };
template struct b;
template <typename, int, typename, bool, typename, bool, int, int> struct c;
template <typename d, int e, typename f, bool g, typename h, bool i, int j>
struct c<d, e, f, g, h, i, a, j> {
typedef typename b::k l;
void m(l *);
};
template <typename d, int e, typename f, bool g, typename h, bool i, int j>
void c<d, e, f, g, h, i, a, j>::m(l *) {}

This small snippet runs without errors in the current master (6e5a666). Can someone confirm if this still happens for the larger case?

[spellcard199]

Can someone confirm if this still happens for the larger case?

Hello, I tried to compile the libfive-rs repo (https://github.com/virtualritz/libfive-rs) mentioned in this thread which still uses bindgen version "0.58.1" released on Apr 6 2021, but it already compiles, so maybe they worked around this issue some other way. In other words, I can't reproduce this issue anymore.

P.S.

Maybe because of some incompatibility with the version of GCC I have installed, to make the C++ side build successfully I had to comment out 2 lines containing the deprecated attribute from $HOME/.cargo/registry/src/git.godevs.top-1ecc6299db9ec823/libfive-sys-0.1.1/, in the files:

• libfive/libfive/include/libfive.h
• libfive/libfive/include/libfive/tree/tree.hpp