You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm back with the same error as before but this time with a bit more information:
First the code is still valid and what I said last time about the buffer size, does NOT fix the problem it HIDES the problem.
From the look of it the problem is with process_vec. The online C example of XZ does not have this defect.
I identfied a way to reproduce the bug: if you must call process_vec more than 3 times in the same Run action you crash it. The next time you call it with more data will be returned with the great "lzma data error".
This means that if you manage to find a large enough output buffer size (with_capacity) for process_vec to use and return the entire decompressed data in exatcly 3 calls, where the first returns the data the second returns 0 and the thrid returns MemNeeded, then the software will continue on the next buffer of compressed data.
If the exact pattern stated previously is not respected (for example the output vec is not large enough) then your software will inevitably crash at the next buffer.
Why is that? Is there a way to prevent that issue?
The text was updated successfully, but these errors were encountered:
Sorry I probably won't be able to help much here. I only lightly maintain this nowadays and the intention was to be very close to the C API so if there's issues it's likely with the C implementation rather than the Rust bindings (in theory). I don't have the time right now to dig in further though.
I'm back with the same error as before but this time with a bit more information:
Why is that? Is there a way to prevent that issue?
The text was updated successfully, but these errors were encountered: