<BISTECTED> Regression: Thread has overflowed it's stack

[Quackdoc]

Bug Description

Steps to reproduce:
Starting with commit: 490f65d I now get the following issue when I run krokiet.

Terminal output (optional):

➜  krokiet git:(28767e9) RUSTFLAGS="-C target-cpu=native -C link-arg=-fuse-ld=mold" RUST_DEBUG=info cargo run --release
   Compiling czkawka_core v8.0.0 (/home/quack/code/czkawka/czkawka_core)
   Compiling krokiet v8.0.0 (/home/quack/code/czkawka/krokiet)
    Finished `release` profile [optimized] target(s) in 2m 52s
     Running `/home/quack/code/czkawka/target/release/krokiet`

thread '<unknown>' has overflowed its stack
fatal runtime error: stack overflow

Debug log

UNCOMMENT DETAILS AND PUT LOGS HERE

System

• Czkawka/Krokiet version: 490f65d
• OS version: Archlinux
• Installation method: Compile

[Quackdoc]

I believe I have further bisected this to the commit: ff8c4c4 I am not sure why this would cause it however

[Quackdoc]

I did manage to get a backtrace using gdb on the thread which looks like a jxl-oxide issue, I would like to test this with upstream jxl-oxide, but I am not sure what image it's failing on to report.

0x0000555556d0e55b in czkawka_core::common_image::get_dynamic_image_from_path ()
(gdb) bt
#0  0x0000555556d0e55b in czkawka_core::common_image::get_dynamic_image_from_path ()
#1  0x0000555556d153e9 in core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once ()
#2  0x0000555556defb27 in rayon::iter::plumbing::Folder::consume_iter ()
#3  0x0000555556d8594d in rayon::iter::plumbing::bridge_producer_consumer::helper ()
#4  0x0000555556f76610 in rayon_core::join::join_context::{{closure}} ()
#5  0x0000555556f80490 in rayon_core::registry::in_worker ()
#6  0x0000555556d85add in rayon::iter::plumbing::bridge_producer_consumer::helper ()
#7  0x0000555556e7af8a in <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute ()
#8  0x0000555557a49bfb in rayon_core::registry::WorkerThread::wait_until_cold ()
#9  0x00005555570eeb36 in rayon_core::registry::Registry::in_worker_cross ()
#10 0x00005555570cd3f0 in jxl_threadpool::JxlThreadPool::scope ()
#11 0x00005555570c34b3 in jxl_render::vardct::render_vardct ()
#12 0x000055555710e2d5 in jxl_render::render::render_frame ()
#13 0x0000555557113975 in jxl_render::RenderContext::render_op::{{closure}} ()
#14 0x00005555570d54d8 in jxl_render::state::FrameRenderHandle<S>::run_with_image ()
#15 0x0000555557114a78 in jxl_render::RenderContext::render_by_index ()
#16 0x0000555557114c05 in jxl_render::RenderContext::render_keyframe ()
#17 0x00005555570263d5 in jxl_oxide::JxlImage::render_frame_cropped ()
#18 0x00005555570263aa in jxl_oxide::JxlImage::render_frame ()
#19 0x0000555556e31467 in <jxl_oxide::integration::image::JxlDecoder<R> as image::image::ImageDecoder>::read_image ()
#20 0x0000555556e291aa in image::image::decoder_to_vec ()
#21 0x0000555556e2b75c in image::dynimage::decoder_to_image ()
#22 0x0000555556d0e47a in czkawka_core::common_image::get_jxl_image ()
#23 0x0000555556d0f154 in czkawka_core::common_image::get_dynamic_image_from_path ()
#24 0x0000555556d153e9 in core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once ()
#25 0x0000555556defb27 in rayon::iter::plumbing::Folder::consume_iter ()
#26 0x0000555556d8594d in rayon::iter::plumbing::bridge_producer_consumer::helper ()
#27 0x0000555556f76610 in rayon_core::join::join_context::{{closure}} ()
#28 0x0000555556f80490 in rayon_core::registry::in_worker ()
#29 0x0000555556d85add in rayon::iter::plumbing::bridge_producer_consumer::helper ()
#30 0x0000555556f76610 in rayon_core::join::join_context::{{closure}} ()

[Quackdoc]

I disabled rayon on jxl-oxide which prevents the issue (but slows down hashing considerably, and viewing the images massively). I did try to create a replication case using the below code, but it works fine. Probably worth doing as rayon was disabled before.

fn main() {
    let args: Vec<String> = env::args().collect();
    if args.len() > 1 {
        let file_path = &args[1];
        let path: &str = file_path;
        let file = File::open(path).unwrap();

        //let img = image::open(original_image_path)?;
        
        // Try to open the image using image-rs, if fails use jxl-oxide
        let img: DynamicImage = match image::open(path) {
            Ok(image) => image,
            Err(_) => {
                // If path 1 fails, try path 2
                let decoder = JxlDecoder::new(file).unwrap();
                image::DynamicImage::from_decoder(decoder).unwrap()
            }
        };

        //let img = image::open(path).unwrap();
        img.save("output.webp").unwrap();
    } else {
            eprintln!("Please provide a file path as a command-line argument.");
        }
}

[qarmin]

In previous versions of app, I had several panics related to stack overflows, so I converted all big arrays to vectors to avoid stack overflows.

I'm not entirely sure what exactly the stack-size record in the binary means after enabling the Rust/LLVM flag, but running:

RUSTFLAGS="-Z emit-stack-sizes" cargo +nightly build
size -A target/debug/krokiet | grep stack_sizes

shows

.stack_sizes           1074566

and with disabled jxl-oxide crate

.stack_sizes           1034152

So, there's not a big difference, which likely explains why the simplified example doesn't crash (probably because other crates, which are not present in the example app, use up more of the stack).