Build fails with --disable-jemalloc

[AndrewScull]

Configuring with ../configure --disable-docs --enable-ccache --disable-jemalloc causes the build to fail with:

x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
Illegal instruction (core dumped)

Usually it is Illegal instruction however sometimes a bad or double free is reported.

Building with jemalloc enabled (../configure --disable-docs --enable-ccache) has no problem.

[huonw]

I can reproduce. Running the aborting command under valgrind gives hundreds of errors like:

==26307== Invalid read of size 8
==26307==    at 0x4E4B4D5: collections..vec..Vec$LT$syntax..ptr..P$LT$syntax..codemap..Spanned$LT$syntax..ast..MetaItem_$GT$$GT$$GT$::glue_drop.12051::h50b8b9a8c4be2bb3 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0xF90490F: ???
==26307==    by 0x2F: ???
==26307==    by 0xD461B9F: ???
==26307==    by 0xD52354F: ???
==26307==    by 0xF5F963F: ???
==26307==    by 0x4E4E8FF: syntax..codemap..Spanned$LT$syntax..ast..Attribute_$GT$::glue_drop.12756::hb78b33cc126cc208 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x8097101EF: ???
==26307==    by 0xC9B2F8F: ???
==26307==    by 0xD461B6F: ???
==26307==    by 0x4EA9E2E: iter::FlatMap$LT$A$C$$u{20}B$C$$u{20}I$C$$u{20}U$C$$u{20}F$GT$.Iterator::next::h11721808144370039366 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x4E9746C: fold::noop_fold_item::h5513282176331594077 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==  Address 0xe5f3240 is 0 bytes inside a block of size 80 free'd
==26307==    at 0x4C29E90: free (vg_replace_malloc.c:473)
==26307==    by 0x4E4B597: collections..vec..Vec$LT$syntax..ptr..P$LT$syntax..codemap..Spanned$LT$syntax..ast..MetaItem_$GT$$GT$$GT$::glue_drop.12051::h50b8b9a8c4be2bb3 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0xF90490F: ???
==26307==    by 0xD46183F: ???
==26307==    by 0xF5F963F: ???
==26307==    by 0xD52354F: ???
==26307==    by 0xC9B2EFF: ???
==26307==    by 0x4E4E8FF: syntax..codemap..Spanned$LT$syntax..ast..Attribute_$GT$::glue_drop.12756::hb78b33cc126cc208 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x4F: ???
==26307==    by 0xC9B2F8F: ???
==26307==    by 0xD4618AF: ???
==26307==    by 0x4EAADA8: fold::noop_fold_impl_item::h7121156065768389895 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307== 
==26307== Invalid read of size 8
==26307==    at 0x4E4B55F: collections..vec..Vec$LT$syntax..ptr..P$LT$syntax..codemap..Spanned$LT$syntax..ast..MetaItem_$GT$$GT$$GT$::glue_drop.12051::h50b8b9a8c4be2bb3 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0xF90490F: ???
==26307==    by 0x2F: ???
==26307==    by 0xD461B9F: ???
==26307==    by 0xD52354F: ???
==26307==    by 0xF5F963F: ???
==26307==    by 0x4E4E8FF: syntax..codemap..Spanned$LT$syntax..ast..Attribute_$GT$::glue_drop.12756::hb78b33cc126cc208 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x8097101EF: ???
==26307==    by 0xC9B2F8F: ???
==26307==    by 0xD461B6F: ???
==26307==    by 0x4EA9E2E: iter::FlatMap$LT$A$C$$u{20}B$C$$u{20}I$C$$u{20}U$C$$u{20}F$GT$.Iterator::next::h11721808144370039366 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x4E9746C: fold::noop_fold_item::h5513282176331594077 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==  Address 0xe5f3248 is 8 bytes inside a block of size 80 free'd
==26307==    at 0x4C29E90: free (vg_replace_malloc.c:473)
==26307==    by 0x4E4B597: collections..vec..Vec$LT$syntax..ptr..P$LT$syntax..codemap..Spanned$LT$syntax..ast..MetaItem_$GT$$GT$$GT$::glue_drop.12051::h50b8b9a8c4be2bb3 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0xF90490F: ???
==26307==    by 0xD46183F: ???
==26307==    by 0xF5F963F: ???
==26307==    by 0xD52354F: ???
==26307==    by 0xC9B2EFF: ???
==26307==    by 0x4E4E8FF: syntax..codemap..Spanned$LT$syntax..ast..Attribute_$GT$::glue_drop.12756::hb78b33cc126cc208 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)
==26307==    by 0x4F: ???
==26307==    by 0xC9B2F8F: ???
==26307==    by 0xD4618AF: ???
==26307==    by 0x4EAADA8: fold::noop_fold_impl_item::h7121156065768389895 (in /home/huon/rust3/build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-4e7c5e5c.so)

[AndrewScull]

I have tracked down the introduction of this crash to the commit: 98d4d49

[huonw]

Wow, thanks for tracking it down, although it's surprising to me, since that commit seems fairly inoccuous. I wonder if one of the other commits in the rollup #21213 may be playing a part too (since those sort of PRs aren't guaranteed to have every commit compiling).

[aidancully]

For what it's worth, I believe the issue is in the stage0 snapshot generating code that can have use-after-free issues. If it's a use-after-free issue (which the valgrind output seems to indicate), the problem's manifestation will be unrelated to the actual patch that generated the panic. While trying to track this down locally, this patch made the problem disappear so that the build ran to completion:

diff --git a/src/libsyntax/fold.rs b/src/libsyntax/fold.rs
index 2a70434..f138ddf 100644
--- a/src/libsyntax/fold.rs
+++ b/src/libsyntax/fold.rs
@@ -1159,6 +1159,7 @@ pub fn noop_fold_item<T: Folder>(i: P<Item>, folder: &mut T) -> SmallVector<P<It
 // fold one item into exactly one item
 pub fn noop_fold_item_simple<T: Folder>(Item {id, ident, attrs, node, vis, span}: Item,
                                         folder: &mut T) -> Item {
+    debug!("noop_fold_item_simple");
     let id = folder.new_id(id);
     let node = folder.fold_item_underscore(node);
     let ident = match node {

[semarie]

@aidancully what is your last known to work build with this workaround ?

[semarie]

Starting from 985fc7d (PR #22200) , the workaround seems to no work anymore for me.

[aidancully]

@semarie: I don't know, I needed --disable-jemalloc for fakeCargo, but I haven't been using fakeCargo since cargo seems to have stopped changing as frequently. So I've been using jemalloc -- only so many hours in the day. That "workaround" was never intended to solve the issue, but rather just to show that the issue seems to be in internal Rust memory management. There is no way that that patch should in any way address the actual issue. (Incidentally, I think this is a serious issue, and suspect that we're just lucky that jemalloc works differently internally than system-malloc does.)

[pnkfelix]

cc me

[alexcrichton]

Seeing how this hasn't cropped up in awhile, I'm gonna close as "presumably fixed" at some point