Segmentation fault in libclang < 5.0 under clang_getFieldDeclBitWidth

[helloqirun]

The hashtag for my bindgen version is 4dd4ac7 .

$ rust-bindgen/target/debug/bindgen abc.h -- -x c++ -std=c++14

Segmentation fault (core dumped)

The header file compiles with clang++ with or without c++14 flag.
$ clang++ -Weverything abc.h

clang-4.0: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]

$ cat abc.h

template < int w > struct _gl_verify_type
{
  unsigned int _gl_verify_error_if_negative:w;
};

[fitzgen]

Looks like this is crashing inside of libclang:

Thread 1 "bindgen" received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416
416	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416
#1  0x00007ffff560501d in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#2  0x00007ffff559d96a in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#3  0x0000555555cdb99a in clang_sys::clang_getFieldDeclBitWidth (cursor=...)
    at /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-0.19.0/src/link.rs:95
#4  0x00005555557973f3 in bindgen::clang::Cursor::bit_width (self=0x7ffffffebce8) at src/clang.rs:467
#5  0x00005555558150bc in bindgen::ir::comp::{{impl}}::from_ty::{{closure}} (cur=...)
    at src/ir/comp.rs:1058
#6  0x0000555555799db4 in bindgen::clang::visit_children<closure> (cur=..., _parent=..., 
    data=0x7ffffffecf50) at src/clang.rs:658
#7  0x00007ffff5521235 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#8  0x00007ffff5524c1d in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#9  0x00007ffff5524d46 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#10 0x00007ffff5520d20 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#11 0x00007ffff5529cd4 in clang_visitChildren () from /usr/lib/llvm-4.0/lib/libclang.so.1
#12 0x0000555555cdd676 in clang_sys::clang_visitChildren (cursor=..., 
    visitor=0x555555799c00 <bindgen::clang::visit_children<closure>>, data=0x7ffffffecf50)
    at /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-0.19.0/src/link.rs:95
#13 0x00005555557969ec in bindgen::clang::Cursor::visit<closure> (self=0x7ffffffed128, visitor=...)
    at src/clang.rs:398
#14 0x00005555558145d5 in bindgen::ir::comp::CompInfo::from_ty (potential_id=..., ty=0x7fffffff3818, 
    location=..., ctx=0x7fffffff51d8) at src/ir/comp.rs:1017
#15 0x0000555555856940 in bindgen::ir::ty::Type::from_clang_ty (potential_id=..., ty=0x7fffffff3818, 
    location=..., parent_id=..., ctx=0x7fffffff51d8) at src/ir/ty.rs:930
#16 0x00005555558493e4 in bindgen::ir::item::{{impl}}::from_ty_with_id (id=..., ty=0x7fffffff3818, 
    location=..., parent_id=..., ctx=0x7fffffff51d8) at src/ir/item.rs:1456
#17 0x00005555558485a8 in bindgen::ir::item::{{impl}}::from_ty (ty=0x7fffffff3818, location=..., 
    parent_id=..., ctx=0x7fffffff51d8) at src/ir/item.rs:1358
#18 0x0000555555846531 in bindgen::ir::item::{{impl}}::parse (cursor=..., parent_id=..., 
    ctx=0x7fffffff51d8) at src/ir/item.rs:1225
#19 0x000055555586e612 in bindgen::parse_one (ctx=0x7fffffff51d8, cursor=..., parent=...)
    at src/lib.rs:1650
#20 0x000055555586ed60 in bindgen::parse::{{closure}}::{{closure}} (cursor=...) at src/lib.rs:1692
#21 0x0000555555799674 in bindgen::clang::visit_children<closure> (cur=..., _parent=..., 
    data=0x7fffffff4240) at src/clang.rs:658
#22 0x00007ffff5521235 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#23 0x00007ffff5524c1d in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#24 0x00007ffff5524d46 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#25 0x00007ffff5520f20 in ?? () from /usr/lib/llvm-4.0/lib/libclang.so.1
#26 0x00007ffff5529cd4 in clang_visitChildren () from /usr/lib/llvm-4.0/lib/libclang.so.1
#27 0x0000555555cdd676 in clang_sys::clang_visitChildren (cursor=..., 
    visitor=0x5555557994c0 <bindgen::clang::visit_children<closure>>, data=0x7fffffff4240)
    at /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-0.19.0/src/link.rs:95
#28 0x0000555555795fef in bindgen::clang::Cursor::visit<closure> (self=0x7fffffff4528, visitor=...)
    at src/clang.rs:398
#29 0x000055555586edad in bindgen::parse::{{closure}} (context=0x7fffffff51d8) at src/lib.rs:1692
#30 0x0000555555832c4a in bindgen::ir::context::BindgenContext::with_module<closure> (
    self=0x7fffffff51d8, module_id=..., cb=...) at src/ir/context.rs:1920
#31 0x000055555586eae8 in bindgen::parse (context=0x7fffffff51d8) at src/lib.rs:1691
#32 0x000055555586cedf in bindgen::Bindings::generate (options=...) at src/lib.rs:1517
#33 0x0000555555869fa2 in bindgen::Builder::generate (self=...) at src/lib.rs:1044
#34 0x000055555562a71f in bindgen::main::{{closure}} () at src/main.rs:55
#35 0x000055555558f6d8 in std::panicking::try::do_call<closure,bindgen::Bindings> (
    data=0x7fffffff9dc0 "\b") at /checkout/src/libstd/panicking.rs:480
#36 0x0000555555dccacd in panic_unwind::__rust_maybe_catch_panic ()
    at /checkout/src/libpanic_unwind/lib.rs:99
#37 0x000055555558f533 in std::panicking::try<bindgen::Bindings,closure> (f=...)
    at /checkout/src/libstd/panicking.rs:459
#38 0x000055555558f296 in std::panic::catch_unwind<closure,bindgen::Bindings> (f=...)
    at /checkout/src/libstd/panic.rs:361
#39 0x0000555555629e0b in bindgen::main () at src/main.rs:54
(gdb) 

[emilio]

Cannot repro on clang 5.0, fwiw.

[sanxiyn]

I think this should be closed. As I understand, bindgen now requires Clang 6.0 or later.

[emilio]

It doesn't really require it, we test on libclang 3.8+. Maybe we should lift some of those requirements though.

[sanxiyn]

Eh oh. My statement was based on dependency to clang-sys with clang_6_0 feature enabled. I stand corrected, but can you explain what's going on here?

[sanxiyn]

I see clang_6_0 feature was added in #1289.

[emilio]

clang_6_0 means that we can optionally use the APIs libclang 6.0 provides, but we runtime-detect them like this

[kulp]

Since this issue disappears at clang 5.0, this issue can probably be closed if and when #2166 merges.

[kulp]

Since #2166 merged, I am closing the current issue.