ICRAR / ijson

100%

master: 100%

LAST BUILD ON BRANCH issue-66

branch: issue-66

CHANGE BRANCH

x

Reset

• issue-66
• travis-xenial
• master
• yajl109_test
• decimal-c
• default_backend
• python_multiple_values
• items_kwargs
• travis-c-ext
• map_type
• v2.5
• reader_conversion
• v2.5.1
• kvitems
• improved-readme
• v2.6.0
• v2.6.1
• travis-more-python
• coros
• more_tests
• design_notes
• v3.0rc1
• fixes-for-known-problems
• coverage-c
• v3.0rc2
• test-comments
• async-string-stream
• async_c
• windows-wheels
• v3.0rc3
• new-devels
• v3.0
• common_functions
• v3.0.1
• yajl2_c_parse_memleak
• v3.0.2
• toplevel_array
• v3.0.3
• empty-members
• v3.0.4
• use_float
• test-module-rename
• items-and-kvitems-dont-join-path
• decoding-errors
• develop
• v3.1
• no-tests-in-binary
• v3.1.post0
• async-fixes
• gh-actions
• v3.1.1
• python-parse-value-clarification
• coverage-increase
• memory-leak
• v3.1.2
• test-wheels-on-travis
• check-3.1.2.post0
• v3.1.2.post0
• zeros-python
• upload-check
• v3.1.3
• issue-42
• issue-41
• v3.1.4
• document-event-interception
• dump
• rtobar-patch-1
• bytes-prefix
• ijson-dumps-multiple
• test
• python-3.10
• update-travis
• release-3.2.0

Build # 294

Build Type

push

travis-ci-com

Committed by rtobar

Commit Message

Avoid decref'ing the sink argument

In #34 memory leaks were reported on the yajl2_c backend that happened
at generator construction time. After investigation, we discovered one
of these in the "chain" utility method, which leaked the temporary
coroutines it chained together. The fix in a8159e4 (first present in
3.1.2) attempted to fix this particular problem, along with the rest of
the identified memory leaks.

The fix for the "chain" method was not correct though: the condition we
used to identify whether the internal "coro" variable had to be decref'd
was incorrect, and led to our code incorrect decref'ing the "sink"
parameter given by the caller, which was meant to be left untouched.
This opened the door to potential issues when the caller decref'd its
reference to "sink".

The problem was not immediately obvious, as depending on the program's
activity, memory allocator and other factors, the memory used by the
destroyed "sink" object could still be valid. In fact our unit tests
never caught this error, and this problem was only reported to us about
a year after 3.1.2 was released by users who saw this problem only after
creating and destroying ijson.parser objects thousands of times.

To reproduce this issue locally I wrote a small script that created a
list of N ijson.parser generators, and then depleted them in order. Only
when running with N=10k I was able to get a failure every 2 or 3
executions.  After applying this patch I saw no failures, so I'm fairly
confident the issue is gone.

This problem was reported originally in #66, which this commit should
fix.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

Run Details

893 of 894 relevant lines covered (99.89%)

8.49 hits per line