Fix ZPipeline.encodeCharsWith flushing to prevent memory leaks
#9938
Conversation
|
|
|
Thank you for your contribution! Would it be possible for you to add tests that pass before and after this modification? |
|
@hearnadam just to confirm I got it correctly, do you mean unit tests that verify the functionality of this pipeline method? Or do you have something else in mind by 'before and after'. |
|
Unit tests for this method. If it passes before and after your PR, it should make sure other users won't see any issues. |
|
I don't think the changes in the code are correct 🤔 Can you please provide a reproduction of the code that you observed an OOM with? |
|
Got a working fix in #10011 |
Addresses #9935.
Ok, the more I think about this, one thing seems clear.
If
CharsetEncoder.encodeis called with theendOfInputargument as true, no further characters are expected to be provided. At this point looping within the localendOfInputmethod shouldn't happen at all.This change seems to fix the memory leak.
What I don't understand is how exactly under the current implementation do subsequent recurse calls of
endOfInputseem to end up withoverflowas result. This doesn't seem too obvious but my assumption is that the encoder itself keeps some internal state that is interpreted as overflow.