repeated thread 'resolver' panicked error messages

[mbihoop]

The program bandwhich works fine as far as I can see, when I execute it with bandwhich 2> /dev/null, otherwise output is obscured by the following error messages which are output every second or so...

thread 'resolver' panicked at 'attempted to leave type `linked_hash_map::Node<proto::op::Query, dns_lru::LruValue>` uninitialized, which is invalid', /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/linked-hash-map-0.5.2/src/lib.rs:174:52
stack backtrace:
   0:        0x10b0c891a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0df5761911c1f774
   1:        0x10b0f4ddb - core::fmt::write::ha5b9ded98b4c0f61
   2:        0x10b0be20a - std::io::Write::write_fmt::h6690dbe9495beb6a
   3:        0x10b0bf095 - std::panicking::default_hook::{{closure}}::hed83fc343d36e583
   4:        0x10b0bec6e - std::panicking::default_hook::h6e54c70328ceb5c9
   5:        0x10b0bf742 - std::panicking::rust_panic_with_hook::h3ae1d1457d0098b2
   6:        0x10b0c8ef4 - std::panicking::begin_panic_handler::{{closure}}::h75a5de43dd9de21e
   7:        0x10b0c8a57 - std::sys_common::backtrace::__rust_end_short_backtrace::h7db746165e445a56
   8:        0x10b0bf183 - _rust_begin_unwind
   9:        0x10b10ff2f - core::panicking::panic_fmt::h5e2322684312195d
  10:        0x10b10fe87 - core::panicking::panic::h9cb062bf8ec44e98
  11:        0x10b00b7c6 - linked_hash_map::LinkedHashMap<K,V,S>::insert::hb5c295970cfaca57
  12:        0x10aff83fe - lru_cache::LruCache<K,V,S>::insert::h1408bdc469cd264f
  13:        0x10b004c91 - trust_dns_resolver::dns_lru::DnsLru::insert::h86d404190fbb52f1
  14:        0x10aef1522 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::he7f159c8715ce844
  15:        0x10aed4ca6 - futures_util::future::future::FutureExt::poll_unpin::h8447ae45eaeabff2
  16:        0x10aed4922 - <trust_dns_resolver::lookup::LookupFuture<C> as core::future::future::Future>::poll::hfebc2d0a7827588e
  17:        0x10aeeba6d - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h2ba8ff78c5fdf644
  18:        0x10aeee7f0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h88540cad6ce8c837
  19:        0x10aeb7ad1 - tokio::task::core::Core<T>::poll::he319c2389257aa09
  20:        0x10af068d5 - tokio::task::harness::Harness<T,S>::poll::h0ff30efd3981b50a
  21:        0x10aeca63a - tokio::runtime::basic_scheduler::SchedulerPriv::tick::h81f578292ab1f7e0
  22:        0x10aebb5cb - std::thread::local::LocalKey<T>::with::h006fbdb7dbb93f18
  23:        0x10aeca96e - tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::h80142316a09321b2
  24:        0x10aebb472 - std::thread::local::LocalKey<T>::with::h0068a1bbe3737972
  25:        0x10aee1594 - tokio::runtime::blocking::BlockingPool::enter::h56043c21f128b504
  26:        0x10aece75f - std::sys_common::backtrace::__rust_begin_short_backtrace::h5a37c5a32fb3fd6e
  27:        0x10af19a16 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb944c48fd85ab0c8
  28:        0x10b0c9877 - std::sys::unix::thread::Thread::new::thread_start::hfdd1cb652f23db83
  29:     0x7ff81e78d4f4 - __pthread_start

[mattolenik]

I'm seeing this on macOS Monterey 12.3.1, currently using this same workaround

[gnoireaux]

Apple M1 Max
Monterey 12.4 (21F79)

-> same errors, same workaround.

[ethanmsl]

Intell chip
macOS Monterey (12.5.1)

+1, & that work-around (calling bandwhich, but sending stderr stream to nega-zone) also works for me -- as in formatting is correct; I can't speak to content

(thx @mbihoop for that btw)

[jlopezr]

I have the same problem on Ubuntu 20.04 on a VPS. Same workaround worked.

[cyqsimon]

Duplicate of #216.

[ethanmsl]

🎊 @ fix announced in #216
(does indeed seem to be working here mac M2 os13.5)
Thanks & Congrats

Edit:
The above comment applies to main branch: (ead54b6 Sept. 2023) .
Noting as my original check was with an aliased version of bandwhich with this thread's workaround builtin.
Unlikely this matters, but in some very specific scenario: well, there ya go. :)