Stack overflow

[damccull]

Hello, I'm trying to use your lib for the first time and just using the basic examples in your docs for reading. I'm getting:

thread 'main' has overflowed its stack
error: process didn't exit successfully: `target\debug\scprospector.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

The zip file was created by 7zip for windows and is attached.
test.zip

How can I get this working?

main.rs

use scprospector::print_p4k_contents;

#[tokio::main]
async fn main() -> Result<(), anyhow::Error> {
    print_p4k_contents().await?;
    Ok(())
}

lib.rs

use async_zip::read::seek::ZipFileReader;
use tokio::fs::File;

pub async fn print_p4k_contents() -> Result<(), anyhow::Error> {
    let mut file = File::open("scprospector.zip").await?;
    dbg!(&file);
    println!("file open; trying to open as zip");
    let mut zip = ZipFileReader::new(&mut file).await?;

    println!("zip open; trying to read first entry");
    let reader = zip.entry_reader(0).await?;
    println!("first entry read; getting crc");
    let txt = reader.read_to_string_crc().await?;

    println!("{}", txt);
    Ok(())
}

It crashes at line let mut zip = ZipFileReader::new(&mut file).await?;.

[Majored]

Ignore the previous comment if you saw it.

Initially thought this could be a stdlib/rustc issue since the overflow was occurring between async function calls, only on Windows (couldn't reproduce on MacOS), and only in debug mode. Whilst it may still be, at least part of the cause seems to be the buffer size chosen for part of the reading. It was 64kb, which doesn't seem insane to me but apparently is too much in debug mode.. I guess?

At least a short term solution is to reduce it down to 16kb I guess, but that does also impact perf.

[Majored]

I'll look into the specifics of this in the future but I've gone and reduced it.

Should be fixed in version 0.0.7. 👍

[damccull]

That sounds like a silly issue. Why would a read buffer of 64kb be too big in debug mode? I'll test moving my code into main for you and get back. Obviously more performance is better.

[damccull]

FYI @Majored, works fine with just main for me too. I asked around on rust discord. Seems the Windows stack is only about 1mb where unix/linux has a higher stack size. So, if you're allocating more than that it's causing an issue. They suggest using a Vec if needing more, which I think is because it stores those on the heap.

[Majored]

Understand that, but that buffer is only ~6% of that stack size on Windows. There really shouldn't be too much else on the stack so the fact that the size is ballooning in debug mode is still just weird to me - along with the fact that removing that single indirection of the print_p4k_contents() fn is the difference between overflowing and not.

I feel like there's something else going on there but honestly, could be completely wrong. I'll leave it as is now with the reduced size. Want to keep everything stack-allocated where it can be.

[damccull]

Ok, just wanted to give you the info I found. I forgot to mention in the previous comment: They also said the compiler may be helpfully optimizing out the stack requirement when it's in main, and just skipping it entirely.

[Majored]

Ah, that makes a lot more sense then.

Thanks :)