sccache panic on linked_hash_map::Node being uninitialized

[PeterGrace]

I am trying to run sccache in a docker container, passing in the S3 (minio) settings via environment variable. cargo build fails without much logging, but, if I fire up the sccache instance in no-fork daemon mode, I am able to get the below backtrace.

app@501a1e077ff5:~/project$ rustc -V
rustc 1.49.0-nightly (f2bbdd0a3 2020-11-04)

    Finished release [optimized] target(s) in 7m 24s
   Replacing /usr/local/cargo/bin/sccache
    Replaced package `sccache v0.2.13` with `sccache v0.2.13` (executable `sccache`)

app@501a1e077ff5:~/project$ SCCACHE_LOG=debug SCCACHE_START_SERVER=1 SCCACHE_NO_DAEMON=1 RUST_BACKTRACE=1 sccache
thread '<unnamed>' panicked at 'attempted to leave type `linked_hash_map::Node<std::path::PathBuf, compiler::rust::RlibDepsDetail>` uninitialized, which is invalid', /rustc/f2bbdd0a3257cc980c
934a92c5bf9808cf31728c/library/core/src/mem/mod.rs:659:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f2bbdd0a3257cc980c934a92c5bf9808cf31728c/library/std/src/panicking.rs:495:5
   1: core::panicking::panic_fmt
             at /rustc/f2bbdd0a3257cc980c934a92c5bf9808cf31728c/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/f2bbdd0a3257cc980c934a92c5bf9808cf31728c/library/core/src/panicking.rs:50:5
   3: linked_hash_map::LinkedHashMap<K,V,S>::insert
   4: lru_disk_cache::lru_cache::LruCache<K,V,S,M>::insert
   5: sccache::compiler::rust::RlibDepReader::discover_rlib_deps
   6: sccache::compiler::rust::RlibDepReader::new_with_check
   7: <futures::future::lazy::Lazy<F,R> as futures::future::Future>::poll
   8: std::panicking::try
   9: <futures::future::catch_unwind::CatchUnwind<F> as futures::future::Future>::poll
  10: <futures_cpupool::MySender<F,core::result::Result<<F as futures::future::Future>::Item,<F as futures::future::Future>::Error>> as futures::future::Future>::poll
  11: futures::task_impl::std::set
  12: futures::task_impl::std::Run::run
  13: futures_cpupool::Inner::work

[gak]

I have the same error on disk storage, no sccache config. Ubuntu 20.04.1 LTS. Built with cargo install and nightly-x86_64-unknown-linux-gnu (default) (all updated today).

[gak]

Work when I build sccache with stable, even when I'm building my project with nightly.

Versions in question:
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.47.0 (18bf6b4f0 2020-10-07)
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.49.0-nightly (25f6938da 2020-11-09)

[PeterGrace]

Yes, when I compile sccache with stable instead of nightly, it works fine. Thanks for the suggestion there. I'm going to close this since it is likely due to nightly volatility rather than an inherent issue with sccache.

[g2p]

I'm getting this when sccache is built with rust 1.48.0, released to stable yesterday.
This should be reopened.

sccache --version
sccache 0.2.13

RUST_BACKTRACE=1 SCCACHE_START_SERVER=1 SCCACHE_NO_DAEMON=1 sccache
thread 'main' panicked at 'attempted to leave type `linked_hash_map::Node<std::ffi::OsString, u64>` uninitialized, which is invalid', /home/g2p/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:658:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::panicking::panic
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:50
   3: linked_hash_map::LinkedHashMap<K,V,S>::insert
   4: lru_disk_cache::lru_cache::LruCache<K,V,S,M>::insert
   5: lru_disk_cache::LruDiskCache::add_file
   6: lru_disk_cache::LruDiskCache::init
   7: lru_disk_cache::LruDiskCache::new
   8: sccache::cache::disk::DiskCache::new
   9: sccache::cache::cache::storage_from_config
  10: sccache::server::start_server
  11: sccache::commands::run_command
  12: sccache::main

[ash2x3zb9cy]

This is caused by lru-disk-cache depending on linked-hash-map v0.2.1. The issue was patched in v0.5.3.
The issue to update the version is here: #813
CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25573
PR that fixes in linked-hash-map: contain-rs/linked-hash-map#100
Hope this info helps.

[glandium]

Per #875 (comment), this means the issue is fixed as of 033ebaa.