Bad EXIF freezes image scanning

[junkfix]

Bug Description
Latest committ stops scanning image at possibly bad image exif
8.0.0 works fine

the same image scans ok once exif is stripped.

Steps to reproduce:
please use possibly_bad_exif.zip image to reproduce.

Terminal output (optional):

 RUST_LOG=debug ./target/release/czkawka_cli  image -d /home/user/test/ -T 1
18:26:22.850 [INFO] czkawka_core::common: App version: 8.0.0, release mode, rust 1.82.0 (2024-10-15), os Ubuntu 22.4.0 [x86_64 64-bit], 8 cpu/threads, features(0): []
18:26:22.851 [DEBUG] czkawka_core::common: Number of threads set to 1
18:26:22.851 [INFO] czkawka_core::similar_images: find_similar_images
18:26:22.851 [DEBUG] czkawka_core::similar_images: check_for_similar_images
18:26:22.851 [DEBUG] czkawka_core::common_dir_traversal: run(collecting files/dirs)
18:26:22.851 [DEBUG] czkawka_core::common: send_info_and_wait_for_ending_all_threads
18:26:22.851 [DEBUG] czkawka_core::common: send_info_and_wait_for_ending_all_threads: Done in 49.36µs
18:26:22.851 [DEBUG] czkawka_core::common_dir_traversal: Collected 1 files
18:26:22.851 [DEBUG] czkawka_core::common_dir_traversal: run(collecting files/dirs): Done in 154.74µs
18:26:22.851 [DEBUG] czkawka_core::similar_images: check_files - Found 1 image files.
18:26:22.851 [DEBUG] czkawka_core::similar_images: check_for_similar_images: Done in 218.63µs
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images_load_cache
18:26:22.851 [DEBUG] czkawka_core::common_cache: load_cache_from_file_generalized_by_path
18:26:22.851 [DEBUG] czkawka_core::common_cache: load_cache_from_file_generalized
18:26:22.851 [DEBUG] czkawka_core::common_cache: Failed to load cache from file cache_similar_images_16_Gradient_Nearest_90.bin because not exists
18:26:22.851 [DEBUG] czkawka_core::common_cache: load_cache_from_file_generalized: Done in 16.21µs
18:26:22.851 [DEBUG] czkawka_core::common_cache: load_cache_from_file_generalized_by_path: Done in 24.74µs
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images-load_cache - starting calculating diff
Collecting files: 1 ▹▹▹▹▹                                                                                                                                                                                                    
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images_load_cache - completed diff between loaded and prechecked files, 1(4.23 MiB) - non cached, 0(0 B) - already cached
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images_load_cache: Done in 64.48µs
Collecting files: 1 ▸▹▹▹▹                                                                                                                                                                                                    
18:26:22.851 [DEBUG] czkawka_core::similar_images: hash_images - start hashing images
Calculating image hashes [====================] 1/1    

...
Killed using pkill -9 czkawka_cli

System

• Czkawka version: 12/10/2024 commit
• OS version: Ubuntu 22.4.0
• Installation method: github build from source

[qarmin]

This is probably fixed by mindeng/nom-exif#17
I will fuzz this library, to find more such invalid situations

[ffchung]

I have the other exif error :

thread '<unnamed>' panicked at /Users/tonyadmin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nom-exif-2.1.0/src/exif/exif_exif.rs:235:5:
assertion failed: data.len() >= 6
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: nom_exif::exif::extract_exif_range
   4: czkawka_core::common_image::get_rotation_from_exif
   5: czkawka_core::common_image::get_dynamic_image_from_path
   6: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
   7: rayon::iter::plumbing::Folder::consume_iter
   8: rayon::iter::plumbing::bridge_producer_consumer::helper
   9: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
  10: rayon_core::registry::WorkerThread::wait_until_cold
  11: rayon_core::registry::ThreadBuilder::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[qarmin]

I reported it as mindeng/nom-exif#21

[ffchung]

I don't know Rust. But I want to ask if that any way to catch the panic and handle it?

[qarmin]

With panic="unwind" - yes(this is what this project uses by default), panic::catch_unwind needs to be used

czkawka/czkawka_core/src/broken_files.rs

Lines 187 to 203 in 1c99adb

	panic::catch_unwind(|| {
	if let Err(e) = image::open(&file_entry.path) {
	let error_string = e.to_string();
	// This error is a problem with image library, remove check when https://github.com/image-rs/jpeg-decoder/issues/130 will be fixed
	if error_string.contains("spectral selection is not allowed in non-progressive scan") {
	return None;
	}
	file_entry.error_string = error_string;
	}
	Some(file_entry)
	})
	.unwrap_or_else(|_| {
	let message = create_crash_message("Image-rs", &file_entry_clone.path.to_string_lossy(), "https://github.com/Serial-ATA/lofty-rs");
	println!("{message}");
	file_entry_clone.error_string = message;
	Some(file_entry_clone)
	})

The biggest problem is with freezing, and this must be fixed in nom-exif library

[ffchung]

common_image.rs :
fn get_rotation_from_exif(path: &str)

something like :

panic::catch_unwind(|| {

	let mut exif_iter: ExifIter = parser.parse(ms)?;
})
.unwrap_or_else(|_| {
	return Ok(None);

});

[ffchung]

The panic is thrown from parser.parse(ms). Need to catch it and handle. For my case it didn't return the rotation as it have panic. So it need to return OK(none) if it fail.