Segmentation fault compiling tinyvec

[mzanrosso]

Hi everyone, as I wrote here LINK I have a problem with a segmentation fault compiling tinyvec.

First of all i have a VM with omnios and when I try to do cargo build on a project that has an indirect dependency tinyvec goes into segmentation fault.

The main specifications of the VM are these:

OS: OmniOS v11 r151030cc i386
CPU: Intel i5-5250U (1) @ 1.600GHz
RAM: 1527MiB
RUSTC: v1.47.0
CARGO: v1.47.0
GCC: 5.5.0

And the console output is this:

error: could not compile `tinyvec`.
Caused by:
  process didn't exit successfully: `rustc --crate-name tinyvec --edition=2018 /home/vagrant/.cargo/registry/src/git.cakeli.workers.dev-1ecc6299db9ec823/tinyvec-1.0.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="tinyvec_macros"' -C metadata=4033b7c8c11b21a1 -C extra-filename=-4033b7c8c11b21a1 --out-dir [PATH OVERWRITTEN] -L dependency=[PATH OVERWRITTEN] --extern tinyvec_macros=[PATH OVERWRITTEN] --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)

[PATH OVERWRITTEN] = real path replaced for privacy

Tell me if you need other things to better understand and solve the problem;
any help we can get here is really appreciated, thank you for your time.

[jyn514]

If you build on a machine with more memory available, does it work? Rustc might be running out of memory.

[nagisa]

Tell me if you need other things

Stack trace from a debugger, please.

[mzanrosso]

If you build on a machine with more memory available, does it work? Rustc might be running out of memory.

Sorry for the delay in answering you; at the moment I don't have the possibility to test it with more ram

[jyn514]

@mzanrosso could you get a stack trace in that case? With GDB it would look like this:

$ gdb rustc
(gdb) run program.rs
(gdb) where

[mzanrosso]

@mzanrosso could you get a stack trace in that case? With GDB it would look like this:

$ gdb rustc
(gdb) run program.rs
(gdb) where

I have never used this tool, is the cargo backtrace okay with you?

[jyn514]

RUST_BACKTRACE won't give you any information because this comes from a segfault. If you're more comfortable using a different debugger that would work too but you won't get it just from environment variables.

[mzanrosso]

RUST_BACKTRACE won't give you any information because this comes from a segfault. If you're more comfortable using a different debugger that would work too but you won't get it just from environment variables.

I am trying cargo with gdb -- run but i get the same error

[nospam3089]

It is very likely an issue of rustc running out of memory, yes. The question is why, and if rustc should be able to handle the situation better than segfault? (Given the nature of the stacktrace, a wild speculation is that the memory might be exhausted even if close to infinite amounts were available.)

When attempting to compiling tinyvec inside a debugger:

echo '::run --crate-name tinyvec --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2  -C metadata=4b183dc7fcc0ca72 -C extra-filename=-4b183dc7fcc0ca72 --out-dir /tinyvec/target/debug/deps -C incremental=/tinyvec/target/debug/incremental -L dependency=/tinyvec/target/debug/deps
::stack' | mdb =rustc > mdb-tinyvec_compilation-20201214.txt 2>&1

the resulting stdout+stderr file has the following interesting property:

% wc -l mdb-tinyvec_compilation-20201214.txt    
    8143 mdb-tinyvec_compilation-20201214.txt
% uniq mdb-tinyvec_compilation-20201214.txt | wc -l
      37

and stacktrace:

mdb: stop on SIGSEGV
mdb: target stopped at:
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xc:pushq  %rbx
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xc()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xf7()

Some eight thousand or so identical lines removed.

librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xf7()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xf7()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate15post_order_walk17h1ba927e80c63146dE.llvm.11573304102894906113+0xf7()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph7iterate18reverse_post_order17h14a472f296e774f5E+0xb2()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5graph10dominators10dominators17hf693ddf6b390a25dE+0x33()
librustc_driver-1b64ce10bf14f7f9.so`_ZN9rustc_mir12borrow_check15do_mir_borrowck17hb6901ddb155d4a91E+0x3ff5()
librustc_driver-1b64ce10bf14f7f9.so`_ZN11rustc_infer5infer16InferCtxtBuilder5enter17h575e70d6ef8079a2E+0x35a()
librustc_driver-1b64ce10bf14f7f9.so`_ZN9rustc_mir12borrow_check12mir_borrowck17h94fdf0a729aa5f85E+0xb0()
librustc_driver-1b64ce10bf14f7f9.so`_ZN4core3ops8function6FnOnce9call_once17hdb8feff01969d913E.llvm.7551448663210073050+0xba()
librustc_driver-1b64ce10bf14f7f9.so`_ZN12rustc_middle2ty5query167_$LT$impl$u20$rustc_query_system..query..config..QueryAccessors$LT$rustc_middle..ty..context..TyCtxt$GT$$u20$for$u20$rustc_middle..ty..query..queries..mir_borrowck$GT$7compute17h2cecb2b80f98140fE.llvm.6927602713281249162+0x5d()
librustc_driver-1b64ce10bf14f7f9.so`_ZN12rustc_middle9dep_graph111_$LT$impl$u20$rustc_query_system..dep_graph..DepKind$u20$for$u20$rustc_middle..dep_graph..dep_node..DepKind$GT$9with_deps17h5b70ea296a506e1eE+0xb1()
librustc_driver-1b64ce10bf14f7f9.so`_ZN18rustc_query_system9dep_graph5graph17DepGraph$LT$K$GT$14with_task_impl17h04f1d713a8755a9eE.llvm.12755491807643063657+0x155()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5stack23ensure_sufficient_stack17h8ea3aa101bda6e48E+0x13a()
librustc_driver-1b64ce10bf14f7f9.so`_ZN18rustc_query_system5query8plumbing14get_query_impl17h9e8f597d62831e7cE+0x15f7()
librustc_driver-1b64ce10bf14f7f9.so`_ZN18rustc_query_system5query8plumbing17ensure_query_impl17hde5dde942d762603E+0x81()
librustc_driver-1b64ce10bf14f7f9.so`_ZN13rustc_session5utils49_$LT$impl$u20$rustc_session..session..Session$GT$4time17h0927eda6b000cfecE+0xec()
librustc_driver-1b64ce10bf14f7f9.so`_ZN15rustc_interface6passes8analysis17h2887bee44801fa69E+0xa4()
librustc_driver-1b64ce10bf14f7f9.so`_ZN12rustc_middle2ty5query163_$LT$impl$u20$rustc_query_system..query..config..QueryAccessors$LT$rustc_middle..ty..context..TyCtxt$GT$$u20$for$u20$rustc_middle..ty..query..queries..analysis$GT$7compute17hf27342b77e7399c6E.llvm.16017345017821477142+0x62()
librustc_driver-1b64ce10bf14f7f9.so`_ZN12rustc_middle9dep_graph111_$LT$impl$u20$rustc_query_system..dep_graph..DepKind$u20$for$u20$rustc_middle..dep_graph..dep_node..DepKind$GT$9with_deps17h68e41ab4a7bbabb3E+0xb4()
librustc_driver-1b64ce10bf14f7f9.so`_ZN18rustc_query_system9dep_graph5graph17DepGraph$LT$K$GT$14with_task_impl17h859b3bf77cdbb2c7E.llvm.16372599754508660169+0x152()
librustc_driver-1b64ce10bf14f7f9.so`_ZN7stacker4grow28_$u7b$$u7b$closure$u7d$$u7d$17h5b8dd305e22f8120E+0x10c()
librustc_driver-1b64ce10bf14f7f9.so`_ZN3psm8on_stack13with_on_stack17hfacdbda4efe79bceE.llvm.11961939084027825792+0x16()
librustc_driver-1b64ce10bf14f7f9.so`rust_psm_on_stack+9()
librustc_driver-1b64ce10bf14f7f9.so`_ZN7stacker5_grow17h155f6513d8746603E+0x151()
librustc_driver-1b64ce10bf14f7f9.so`_ZN21rustc_data_structures5stack23ensure_sufficient_stack17hc590c2d490d134e1E+0xdb()
librustc_driver-1b64ce10bf14f7f9.so`_ZN18rustc_query_system5query8plumbing14get_query_impl17h34c8d11d1c0d27b0E+0x135e()
librustc_driver-1b64ce10bf14f7f9.so`_ZN15rustc_interface6passes12QueryContext5enter17hf7dfedbaec3b7333E+0x6d()
librustc_driver-1b64ce10bf14f7f9.so`_ZN15rustc_interface7queries54_$LT$impl$u20$rustc_interface..interface..Compiler$GT$5enter17h71ba50b918065223E+0x640()
librustc_driver-1b64ce10bf14f7f9.so`_ZN10rustc_span15with_source_map17hf43c9dea61733997E+0x161()
librustc_driver-1b64ce10bf14f7f9.so`_ZN10scoped_tls18ScopedKey$LT$T$GT$3set17h2e81b42d0e97dbf6E+0x4a2()
librustc_driver-1b64ce10bf14f7f9.so`_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h736ac4be3fbcc2dfE+0x208()
librustc_driver-1b64ce10bf14f7f9.so`_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17hc062386eb20c48f0E+0x4c()
libstd-12999f405e7cf11f.so`_ZN3std3sys4unix6thread6Thread3new12thread_start17h65240c393be2e6f5E+0x2b()
libc.so.1`_thrp_setup+0x8a(fffffc7fed8c0280)
libc.so.1`_lwp_start()

The compilation above is against faa03b21 of tinyvec from msgh, but it also happens with any recent released version. The rustc used comes from version 1.48.0-151030.0 of the ooce/developer/rust package of the extra.omnios IPS repository.

I have not made any analysis on what tinyvec actually does, whether the code is written correctly, or if it indeed should fail to compile. I do believe code shouldn't manage to crash the compiler though, and assume you would agree on at least that last part?

[smklein]

FYI, this looks like a dup of #79438

[Lokathor]

@nospam3089 tinyvec is a 100% safe version of the smallvec / arrayvec crates. It's like a Vec but uses an array instead of a heap allocation below a certain size.

It's written correctly as far as I know (tens of thousands of downloads a day off of crates.io, no significant bugs reported), and should not crash the compiler to build.

[nospam3089]

I was unable to reproduce this with 1.49.0, and agree it does indeed look very similar to 79438.

I would suggest @mzanrosso, the ticket owner, to verify and either close this ticket or mark it as a duplicate as applicable.

[jyn514]

#78607 landed in 1.49, which was released today.