BIND 10 #1359: reference leak in python log wrapper
BIND 10 Development
do-not-reply at isc.org
Wed Nov 16 07:46:18 UTC 2011
#1359: reference leak in python log wrapper
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: accepted
Type: | Milestone:
defect | Sprint-20111122
Priority: major | Resolution:
Component: | Sensitive: 0
logging | Sub-Project: Core
Keywords: | Estimated Difficulty: 4
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
trac1359 is ready for review.
I've found a more critical leak in the log wrapper, and succesfully
reproduced clear memory leak with the following simple test code:
{{{
while True:
name = isc.dns.Name('example.com')
rrclass = isc.dns.RRClass('IN')
logger.info(XFRIN_XFR_TRANSFER_SUCCESS, 'AXFR',
name.to_text(True) + '/' + str(rrclass))
logger.error(XFROUT_CC_SESSION_TIMEOUT_ERROR)
}}}
(of course you'll need to import necessary modules and set PYTHONPATH,
etc,
properly).
I've fixed the leak in this branch, and confirmed it completely solves
this type of memory leak.
Since the main fix is pretty small and (I believe) straightforward,
I've also made some additional cleanups (some of which are actually
not just for cleanness but fixes rare exception safety bugs). The
main fix is the first two commits. If the additional changes are
deemed to be beyond the scope of this ticket, I'm okay with deferring
them to a separate ticket.
This is the proposed changelog entry:
{{{
317. [bug] jinmei
Fixed reference leak in the isc.log Python module. Most of all
BIND 10 Python programs had memory leak (even though the pace of
leak may be slow) due to this bug.
(Trac #1359, git TBD)
}}}
BTW, this is totally unrelated to this ticket, but I've been also
noticing that in the python log wrapper converts the expensive
conversion from objects to string for all log levels. I guess this
has non negligible performance impact even if performance is
relatively less crucial for python programs. I wonder whether we
should do the isXXXEnabled() check in Logger_debug(), etc, before
calling Logger_performOutput. Would that be worth trying, maybe
in a separate ticket?
--
Ticket URL: <http://bind10.isc.org/ticket/1359#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list