build-script-build (signal: 11, SIGSEGV: invalid memory reference)

[bbigras]

I'm able to build this on Arch 64-bit but not on Ubuntu trusty 32-bit. I'm wondering if the cause could be the 32-bit part.

$ export LIBCLANG_PATH=/usr/lib/llvm-3.9/lib
$ export LD_LIBRARY_PATH=/usr/lib/llvm-3.9/lib
$ RUST_LOG=libbindgen RUST_BACKTRACE=1 cargo build
   Compiling bindgen-sigsegv v0.1.0 (file:///home/bbigras/bindgen-sigsegv/bindgen-sigsegv)
error: failed to run custom build command for `bindgen-sigsegv v0.1.0 (file:///home/bbigras/bindgen-sigsegv/bindgen-sigsegv)`
process didn't exit successfully: `/home/bbigras/bindgen-sigsegv/bindgen-sigsegv/target/debug/build/bindgen-sigsegv-3d591becf77542af/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
--- stdout
cargo:rustc-link-lib=gssapi_krb5

Ubuntu 14.04.5 LTS (32-bit)
clang-3.9
bindgen 0.20.0

Cargo.toml

[package]
name = "bindgen-sigsegv"
version = "0.1.0"
build = "build.rs"

[build-dependencies]
bindgen = "0.20"

lib.rs

#![allow(non_camel_case_types)]
#![allow(dead_code)]
include!(concat!(env!("OUT_DIR"), "/bindings.rs"));

build.rs

extern crate bindgen;
use bindgen::Builder;

use std::env;
use std::path::PathBuf;

fn main() {
    println!("cargo:rustc-link-lib=gssapi_krb5");

    let bindings = Builder::default()
        .no_unstable_rust()
        .header("wrapper.h")
        .whitelisted_function("gss.*")
        .whitelisted_function("GSS.*")
        .whitelisted_type("gss.*")
        .whitelisted_type("GSS.*")
        .generate()
        .expect("Unable to generate bindings");

    let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
    bindings.write_to_file(out_path.join("bindings.rs"))
        .expect("Couldn't write bindings!");
}

wrapper.h

#include <gssapi/gssapi.h>

[Yamakaky]

I had trouble on 32bit with upstream bindgen.

[fitzgen]

Thanks for the bug report!

Care to run this under gdb or lldb and dump the output of bt in here?

[bbigras]

$ gdb --args cargo build
(gdb) run
Starting program: /home/bbigras/.cargo/bin/cargo build
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
   Compiling bindgen-sigsegv v0.1.0 (file:///home/bbigras/bindgen-sigsegv/bindgen-sigsegv)
error: failed to run custom build command for `bindgen-sigsegv v0.1.0 (file:///home/bbigras/bindgen-sigsegv/bindgen-sigsegv)`
process didn't exit successfully: `/home/bbigras/bindgen-sigsegv/bindgen-sigsegv/target/debug/build/bindgen-sigsegv-3d591becf77542af/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
--- stdout
cargo:rustc-link-lib=gssapi_krb5

[Inferior 1 (process 18211) exited with code 0145]
(gdb) bt
No stack.

not sure how to use lldb:

$ lldb-3.9 cargo build
(lldb) target create "cargo"
error: '/home/bbigras/.cargo/bin/cargo' doesn't contain any 'host' platform architectures: i686

[emilio]

That only gives you the backtrace of cargo, could you check with gdb --args /home/bbigras/bindgen-sigsegv/bindgen-sigsegv/target/debug/build/bindgen-sigsegv-3d591becf77542af/build-script-build instead? That would help track it down.

Thanks for reporting this! :)

[bbigras]

(gdb) run
Starting program: /home/bbigras/bindgen-sigsegv/bindgen-sigsegv/target/debug/build/bindgen-sigsegv-3d591becf77542af/build-script-build 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
cargo:rustc-link-lib=gssapi_krb5

Program received signal SIGSEGV, Segmentation fault.
0xbfffc6a8 in ?? ()
(gdb) bt
#0  0xbfffc6a8 in ?? ()
#1  0xb7fff938 in _r_debug ()
#2  0xb7ff24b0 in ?? () from /lib/ld-linux.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) bt full
#0  0xbfffc6a8 in ?? ()
No symbol table info available.
#1  0xb7fff938 in _r_debug ()
No symbol table info available.
#2  0xb7ff24b0 in ?? () from /lib/ld-linux.so.2
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[Yamakaky]

Could you compile bindgen on debug ?

[emilio]

That's seemed like a debug build (it's under target/debug).

That's I think the less useful backtrace I've ever seen, heh. Thanks for providing it though, much appreciated.

It seems this is not a bindgen problem per se, the _r_debug symbol seems to come from glibc (https://fossies.org/dox/glibc-2.24/dl-debug_8c.html#a21f3d9a72cb7e0ce2f3bdfb3f55bedef).

I think that this may be a libclang.so problem (this seems to happen while loading libclang?). May you try to do a local LLVM build and try with LIBCLANG_PATH set to that?

It's going to take a while (I don't even know if the memory requirements to build LLVM can be fullfilled with a 32-bit build?). In any case, you can do it with:

$ git clone https://github.com/llvm-mirror/llvm
$ cd llvm/tools
$ git clone https://github.com/llvm-mirror/clang
$ cd .. # To the llvm folder
$ mkdir build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Debug && make

After that, libclang should be in build/lib. If you could try loading that library and doing the same that'd be great.

[bbigras]

I don't even know if the memory requirements to build LLVM can be fullfilled with a 32-bit build

I didn't have enough memory (I only had 3 GB and some was in use). I'll try on a bigger VM. Unless there's another solution.

[jeandudey]

The solution is very easy (i think), when i was working in the remacs codebase i came up with a similar issue (remacs/remacs#95), this was because the code was using newtypes, and in 32 bits they aren't passed correctly between C and Rust code, unlike 64 bits code.

Currently clang-sys is using newtypes as opaque structs declared with the opaque! macro.

An example of this is CXIndex in clang-sys and, of course, other opaque! types.

See rust-lang/rust#39394 for the explanation of why newtypes behave different than normal types.

[emilio]

Oh, of course. That also explains why that didn't happen in the old bindgen before the clang-sys switch.

It's a pity because we're also generating newtypes for bitfield-like enums.

I agree this definitely needs, at least, some documentation (this is such a common pattern that nobody of the reviewers, among which there were rustc people, noticed this).

Ideally we would actually have some compiler magic for this, since this is both a common idiom and really convenient. Treating newtypes as the underlying type regarding ABI may not be a bad idea, but it's a breaking change of course. Maybe it's worth an rfc though?

In any case, cc @KyleMayes, this probably needs (another) libclang redesign plus breaking change I fear :/

[emilio]

Thanks @jeandudey for the comment, this would have required much more time to debug otherwise!

[KyleMayes]

v0.13.0 of clang-sys has just been released with all the newtype pointer wrappers changed to raw pointers.

[emilio]

This also affects all the enums and similar as far as I know though