Crash when using zune_png on embedded ESP32, no_std

[yanshay]

I'm using zune-png to decode an image on ESP32 no_std and with async (using embassy). Probably not the most standard setup.

After I use decode_into, or decode_raw, the function returns but right after the system crash stating it encounterd an illegal instruction, as if the decode method overran code memory. Note that the crash is on another task (but on the same thread/core if that matters).

I'm doing it with a small 16x16 8bit png, so it's not lack of memory, I also overran the buffer with data (instead of decode) to test if its the buffer that somehow got mixed with code, but that also doesn't seem to be the issue.
I also disabled the unsafe code in options.

Does decode_into uses some unsafe code underneath that could cause such memory overruns?
Does it maybe need a lot of stack memory and maybe it overran the stack that way?
Any other ideas on how to troubleshoot this?

[etemesi254]

hi,

if you aren't running with unsafe feature the only other unsafe line is

zune-image/crates/zune-png/src/utils.rs

Line 354 in 2c4cb4e

pub fn convert_u16_to_u8_slice(slice: &mut [u16]) -> &mut [u8] {

used when one requests 16 bit to 8 bit conversion which satisfies all invariants for safety( bytemuck can do it, just didn't want the dependency)

I'm not an expert in embedded environments but is it possible to run gdb on the binary or in any way capture a kernel dump? might help dignose

I'm thinking it might be a stack issue as I may have gotten a bit careless with that

Is it also okay if you share the image?

[yanshay]

It does seem to be a stack issue. I reduced the size of the heap, so more space is available for the stack, so now the 16x16 is working, but 64x64 cause for the issues which are now different, looks like different memory overruns.

How much processing memory is required to decode a png? I wanted to assume that not much would be required in addition to the resulting image buffer, but maybe I should pick a different format since I'm low on memory?
I need the file+result buffer+processing memory to be as low as possible, performance is less important for me, I do it just once per image and not many images.

[etemesi254]

Hi the library definitely over-allocates on PNG, the space is usually 2x-3x the image size. There are ways to reduce this but that would slow down other processes

The memory can be calculated by

• (width+1)*height*colorspace_components for the zlib decoding library, we could decode per line hence to width+1 but that would need a really big change in the zlib backend which I once thought of and saw it non-viable
• image size if we are going to convert it from 16 bit to 8 bit
• image size if we are allocating the output

Alternatives:
For your size, you should probably stay away from complex formats like jpeg and png

• qoi : Many QOI decoders will not allocate anything except a 256 byte table, and decoders are fast.

• bmp : If you want better support outside of your environment, zune-bmp will not allocate huge buffers in the heap unless you use RLE encoded images(rarely used), if you stick to paletted images or normal bmps, we guarantee image with minimal allocations

• You can consider also spng, if you stick with png, I'm not sure if it works in embedded environments but has a better memory handling situation

Hope that helps