mohrezaei/thincollections

Appending an empty ThinVec causes segfault.

Closed this issue · 2 comments

Tested with thincollections@0.5.2 .

extern crate thincollections;
use thincollections::thinvec;

fn main() {
  let mut a = thinvec![1];
  let mut b = thinvec![];
  a.append(&mut b);
}
lldb target/debug/thinvec
(lldb) target create "target/debug/thinvec"
Current executable set to 'target/debug/thinvec' (x86_64).
(lldb) run
Process 36902 launched: '/Users/Ron/thinvec/target/debug/thinvec' (x86_64)
Process 36902 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffff)
    frame #0: 0x0000000100002037 thinvec`_$LT$thincollections..thin_vec..ThinVec$LT$T$GT$$GT$::append::h03601423c7a8cc57(self=0x00007ffeefbff6a0, other=0x00007ffeefbff6b8) at thin_vec.rs:1111
   1108	        unsafe {
   1109	            self.append_elements(other.as_slice() as _);
   1110	            let len_ptr = other.u.get() as *mut usize;
-> 1111	            *len_ptr = 0;
   1112	        }
   1113	    }
   1114
Target 0: (thinvec) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffff)
  * frame #0: 0x0000000100002037 thinvec`_$LT$thincollections..thin_vec..ThinVec$LT$T$GT$$GT$::append::h03601423c7a8cc57(self=0x00007ffeefbff6a0, other=0x00007ffeefbff6b8) at thin_vec.rs:1111
    frame #1: 0x0000000100002df9 thinvec`thinvec::main::h80f25aa9a59242c8 at main.rs:7
    frame #2: 0x0000000100000ed2 thinvec`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h3004671de9d98f0c at rt.rs:74
    frame #3: 0x000000010000fe98 thinvec`std::panicking::try::do_call::hcfe6ac53944e0624 [inlined] std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hf8f54988cfbc241e at rt.rs:59 [opt]
    frame #4: 0x000000010000fe8c thinvec`std::panicking::try::do_call::hcfe6ac53944e0624 at panicking.rs:310 [opt]
    frame #5: 0x000000010001c61f thinvec`__rust_maybe_catch_panic at lib.rs:103 [opt]
    frame #6: 0x000000010000bd4d thinvec`std::rt::lang_start_internal::hb972e1f76be57958 [inlined] std::panicking::try::h9432f7e8ae11f605 at panicking.rs:289 [opt]
    frame #7: 0x000000010000bd1a thinvec`std::rt::lang_start_internal::hb972e1f76be57958 [inlined] std::panic::catch_unwind::haeea9805caae6d4d at panic.rs:392 [opt]
    frame #8: 0x000000010000bd1a thinvec`std::rt::lang_start_internal::hb972e1f76be57958 at rt.rs:58 [opt]
    frame #9: 0x0000000100000eb2 thinvec`std::rt::lang_start::h9fe92eb28ef6e37d(main=(thinvec`thinvec::main::h80f25aa9a59242c8 at main.rs:4), argc=1, argv=0x00007ffeefbff880) at rt.rs:74
    frame #10: 0x0000000100002e82 thinvec`main + 34
    frame #11: 0x00007fff68cb0085 libdyld.dylib`start + 1
(lldb)
rustc -Vv
rustc 1.30.0 (da5f414c2 2018-10-24)
binary: rustc
commit-hash: da5f414c2c0bfe5198934493f04c676e2b23ff2e
commit-date: 2018-10-24
host: x86_64-apple-darwin
release: 1.30.0
LLVM version: 8.0

Thanks for the bug report/repro. I'll have a look.

Fixed the issue and published 0.5.3. Thanks again for the report.