New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix gif OOM when decoding #1696
Conversation
Hmm,, I'm getting a failure
Looks to be the Ah, looks to be an intended failure. |
cac78c2
to
7aebc74
Compare
src/codecs/gif.rs
Outdated
|
||
let mut frame_buffer = vec![0; buffer_size]; | ||
|
||
self.limits.free( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the reserve/free API is good, but I needed to free
earlier than this buffer is actually freed to avoid the limits not actually being reset (in the event of a EOF when reading, I want to reset the limits back to what they were when we were given it).
Maybe an alternate API like a Limits
being an Allocator wrapper would be useful. Not sure! Probably best to just get more examples of code that use the limits API and then see what fits them the best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably correct, an allocator API would be interesting but it would need to interact with all containers. Vec
and Box
is potentially a good start but not generic enough. But it's hard to say if it was better to wait on an the allocator interface or to solve it separately.
Given that there is no concurrency in this specific, I would say the order doesn't matter to here. The only effect of free is to allow following reserve
calls to succeed.
No description provided.