Bug#976577: librsvg: FTBFS: panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid'

[Simon McVittie]

Control: retitle -1 librsvg: FTBFS: panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid'
Control: tags -1 + upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/librsvg/-/issues/674

On Sat, 05 Dec 2020 at 14:06:19 +0100, Lucas Nussbaum wrote:
> > ---- cmdline::rsvg_convert::env_source_data_epoch_controls_pdf_creation_date stdout ----
> > thread 'cmdline::rsvg_convert::env_source_data_epoch_controls_pdf_creation_date' panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid', /usr/src/rustc-1.48.0/library/core/src/mem/mod.rs:658:9
> > note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> > 
> > ---- cmdline::rsvg_convert::multiple_input_files_create_multi_page_pdf_output stdout ----
> > thread 'cmdline::rsvg_convert::multiple_input_files_create_multi_page_pdf_output' panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid', /usr/src/rustc-1.48.0/library/core/src/mem/mod.rs:658:9
> > 
> > ---- cmdline::rsvg_convert::output_format_pdf stdout ----
> > thread 'cmdline::rsvg_convert::output_format_pdf' panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid', /usr/src/rustc-1.48.0/library/core/src/mem/mod.rs:658:9
> > 
> > ---- cmdline::rsvg_convert::pdf_page_size stdout ----
> > thread 'cmdline::rsvg_convert::pdf_page_size' panicked at 'attempted to leave type `linked_hash_map::Node<std::vec::Vec<u8>, object::Object>` uninitialized, which is invalid', /usr/src/rustc-1.48.0/library/core/src/mem/mod.rs:658:9

This is a known thing upstream, which was resolved by updating the
vendored copy of the lopdf crate. I'm hoping this will be fixed in a
2.50.3 release soon so we don't have to figure out which precise change
fixes this.

I'm not sure why this is happening with rustc 1.48 - the upstream issue
suggests that this is a new failure with rustc 1.49, but perhaps our
rustc has a backported patch?

    smcv