Fix a memory leak introduced in #6418 #6778
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@thebrianchen Brian, notifying you just to keep you in the loop. |
paulb777
pushed a commit
that referenced
this pull request
Oct 20, 2020
The root of the issue is that when serializing a singular filter, it is being treated as a unary filter before it is definitively established whether it is a unary filter or a field filter. The leak is caused by always serializing the unary filter's field path field for equality and non-equality filters -- if the filter's value turns out not to be NaN or null, the serialization code switches the filter's type to a field filter without clearing the partially-initialized unary filter. `pb_release` would not free the `unary_filter.field.field_path` member variable because it would consider the object not to be a unary filter. Also a small refactoring to make the function easier to digest.
paulb777
pushed a commit
that referenced
this pull request
Oct 20, 2020
The root of the issue is that when serializing a singular filter, it is being treated as a unary filter before it is definitively established whether it is a unary filter or a field filter. The leak is caused by always serializing the unary filter's field path field for equality and non-equality filters -- if the filter's value turns out not to be NaN or null, the serialization code switches the filter's type to a field filter without clearing the partially-initialized unary filter. `pb_release` would not free the `unary_filter.field.field_path` member variable because it would consider the object not to be a unary filter. Also a small refactoring to make the function easier to digest.
paulb777
added a commit
that referenced
this pull request
Oct 20, 2020
The root of the issue is that when serializing a singular filter, it is being treated as a unary filter before it is definitively established whether it is a unary filter or a field filter. The leak is caused by always serializing the unary filter's field path field for equality and non-equality filters -- if the filter's value turns out not to be NaN or null, the serialization code switches the filter's type to a field filter without clearing the partially-initialized unary filter. `pb_release` would not free the `unary_filter.field.field_path` member variable because it would consider the object not to be a unary filter. Also a small refactoring to make the function easier to digest. Co-authored-by: Konstantin Varlamov <[email protected]>
The root of the issue is that when serializing a singular filter, it is being treated as a unary filter before it is definitively established whether it is a unary filter or a field filter. The leak is caused by always serializing the unary filter's field path field for equality and non-equality filters -- if the filter's value turns out not to be NaN or null, the serialization code switches the filter's type to a field filter without clearing the partially-initialized unary filter.
pb_releasewould not free theunary_filter.field.field_pathmember variable because it would consider the object not to be a unary filter.Also a small refactoring to make the function easier to digest.