Panic when reading file, manually assembling it and saving to vector

[qarmin]

Dicom-rs 26cb283

Sadly I cannot provide exact steps to reproduce problem, because this depends on our proprietary library.

When running code similar to (logic is very similar to code from below, but we additionally decompose entire file and compose it again)

pub fn test_items() {
    let file_path = "/opt/BROKEN_FILES_DIR/image-00000_IDX_0_RAND_1471178784642623661843127_minimized_519.dcm";
    let Ok(file) = dicom_object::OpenFileOptions::new().open_file(file_path) else {
        println!("Error opening file");
        return;
    };
    let transfer_syntax = file.transfer_syntax_uid();

    let mut object_data = Vec::with_capacity(2048);
    let Some(ts_selected) = dicom_transfer_syntax_registry::TransferSyntaxRegistry
        .get(transfer_syntax)
         else {
             println!("Unsupported transfer syntax");
             return;
         };
    let _ = file.write_dataset_with_ts(&mut object_data, ts_selected); // Here, instead file we collect elements in hierarchy 

    let mut new_dicom_obj = InMemDicomObject::new_empty();
    for elem in file {
        new_dicom_obj.put_element(elem);
    }
    let _ = new_dicom_obj.write_dataset_with_ts(&mut object_data, ts_selected);


    println!("DONE");
}

I have crash

thread 'main' panicked at 'internal error: entered unreachable code', /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-parser-0.8.0/src/dataset/mod.rs:538:82
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:117:5
   3: <dicom_parser::dataset::DataElementTokens<I,P> as core::iter::traits::iterator::Iterator>::next
             at /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-parser-0.8.0/src/dataset/mod.rs:538:82
   4: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/alloc/src/vec/spec_from_iter_nested.rs:26:32
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/alloc/src/vec/spec_from_iter.rs:33:9
   6: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/alloc/src/vec/mod.rs:2696:9
   7: <alloc::collections::vec_deque::VecDeque<T> as alloc::collections::vec_deque::spec_from_iter::SpecFromIter<T,I>>::spec_from_iter
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/alloc/src/collections/vec_deque/spec_from_iter.rs:17:9
   8: <alloc::collections::vec_deque::VecDeque<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/alloc/src/collections/vec_deque/mod.rs:2758:9
   9: core::iter::traits::iterator::Iterator::collect
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/iter/traits/iterator.rs:1895:9
  10: <dicom_object::tokens::InMemObjectTokens<E> as core::iter::traits::iterator::Iterator>::next
             at /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-object-0.8.0/src/tokens.rs:67:35
  11: dicom_parser::dataset::write::DataSetWriter<W,E>::write_sequence
             at /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-parser-0.8.0/src/dataset/write.rs:159:22
  12: dicom_object::mem::InMemDicomObject<D>::write_dataset_with_ts_cs
             at /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-object-0.8.0/src/mem.rs:1789:9
  13: dicom_object::mem::InMemDicomObject<D>::write_dataset_with_ts
             at /home/rafal/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dicom-object-0.8.0/src/mem.rs:1807:9
  14: <dicom_ciod::ciod::KnownCIOD as dicom_scu::ciod::CIODDumper>::dump
             at /home/rafal/Projekty/dicom-scu/src/ciod.rs:16:9
  15: dicom_scu::client::store::create_and_send
             at /home/rafal/Projekty/dicom-scu/src/client/store.rs:138:23
  16: dicom_scu::client::c_store
             at /home/rafal/Projekty/dicom-scu/src/client.rs:64:5
  17: dicom_scu::TCPAssociation::c_store
             at /home/rafal/Projekty/dicom-scu/src/lib.rs:50:13
  18: c_store::main
             at /home/rafal/Projekty/dicom-scu/src/bin/c_store.rs:61:17
  19: core::ops::function::FnOnce::call_once
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

in

dicom-rs/parser/src/dataset/mod.rs

Line 538 in 26cb283

Value::Primitive(_) | Value::PixelSequence { .. } => unreachable!(),

the problematic files

BROKEN_FILES_DIR.zip

[Enet4]

we additionally decompose entire file and compose it again

I could not exactly reproduce the problem using these examples, but that process may have produced invalid sequence data elements in memory. These cases were treated as unreachable, though one can indeed reach them programmatically by building these objects in code. I have added some robustness to the token writing algorithm in #628, please take a look and see if it helps your use case.