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

virtualritz · 2021-04-20T19:41:32Z

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.

The text was updated successfully, but these errors were encountered:

emilio · 2021-04-20T20:15:01Z

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

virtualritz · 2021-04-20T22:07:47Z

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 · 2021-04-20T22:20:28Z

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 · 2021-04-21T09:10:06Z

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 · 2021-04-21T09:41:48Z

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 · 2021-04-21T09:42:54Z

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

spellcard199 · 2021-04-26T19:19:50Z

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:

Install dependencies:

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

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 · 2021-05-02T23:31:34Z

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 · 2021-05-03T03:05:00Z

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 · 2021-05-07T10:05:06Z

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

pvdrz · 2022-11-23T18:12:09Z

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 · 2022-12-11T18:49:09Z

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/jiasu.xzqcsaa.nyc.mn-1ecc6299db9ec823/libfive-sys-0.1.1/, in the files:

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

SWW13 mentioned this issue Jan 24, 2023

SIGSEGV / Segfault in 0.61.0 #2395

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

virtualritz commented Apr 20, 2021 •

edited

Loading

emilio commented Apr 20, 2021

Uh oh!

virtualritz commented Apr 20, 2021

Uh oh!

virtualritz commented Apr 20, 2021

Uh oh!

emilio commented Apr 21, 2021

Uh oh!

virtualritz commented Apr 21, 2021

Uh oh!

virtualritz commented Apr 21, 2021

Uh oh!

spellcard199 commented Apr 26, 2021

Uh oh!

boydjohnson commented May 2, 2021

Uh oh!

boydjohnson commented May 3, 2021

Uh oh!

kulp commented May 7, 2021

Uh oh!

pvdrz commented Nov 23, 2022

Uh oh!

spellcard199 commented Dec 11, 2022

Uh oh!

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

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

Comments

virtualritz commented Apr 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

emilio commented Apr 20, 2021

Uh oh!

virtualritz commented Apr 20, 2021

Uh oh!

virtualritz commented Apr 20, 2021

Uh oh!

emilio commented Apr 21, 2021

Uh oh!

virtualritz commented Apr 21, 2021

Uh oh!

virtualritz commented Apr 21, 2021

Uh oh!

spellcard199 commented Apr 26, 2021

Uh oh!

boydjohnson commented May 2, 2021

Uh oh!

boydjohnson commented May 3, 2021

Uh oh!

kulp commented May 7, 2021

Uh oh!

pvdrz commented Nov 23, 2022

Uh oh!

spellcard199 commented Dec 11, 2022

Uh oh!

virtualritz commented Apr 20, 2021 •

edited

Loading