<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Bedrich,<br>
<br>
I've applied the patch in trunk.<br>
Thanks!<br>
<br>
Willem<br>
<br>
Op 04-05-11 09:26, Bedrich Kosata schreef:<br>
<span style="white-space: pre;">> Hi Willem,<br>
><br>
> by looking at the current SVN code, I found out, that I
actually did not include part of the code into the patch I sent
last time.<br>
> This is the part about RRSIG checking - marked in my last
post below.<br>
> I am attaching the patch for ldns_rr.i now.<br>
><br>
> Best regards<br>
><br>
> Beda<br>
><br>
> p.s.- I am currently working on some more memory issues
related to rr and rdf sharing the same data. I hope to be able to
send something soon.<br>
><br>
><br>
> On 04/13/2011 04:54 PM, Willem Toorop wrote:</span><br>
<blockquote type="cite">Hi Bedrich,<br>
<br>
I've applied your patches in trunk.<br>
The tests run all fine with me.<br>
Thanks for fixing this.<br>
<br>
Best regards, Willem<br>
<br>
<br>
On 04/13/11 08:45, Bedrich Kosata wrote:<br>
>>> Hi again,<br>
>>><br>
>>> as nobody seemed to have anything against my
proposal, I prepared the<br>
>>> patches that should fix the problems I outlined
before :)<br>
>>><br>
>>> When the patches are applied, the python bindings
should always have<br>
>>> rr_list and rr structs separated in memory. This is
accomplished by<br>
>>> always cloning rr data when either adding them to an
rr_list or<br>
>>> retrieving them from the rr_list.<br>
<br>
> This was not in the last patch..<br>
<br>
>>> Most of the changes should be transparent and should
not require<br>
>>> modifications to existing code. The only outside
change I had to make<br>
>>> was in the "ldns_verify_rrsig_keylist_notime" and<br>
>>> "ldns_verify_rrsig_keylist" functions, because it
copies pointers to the<br>
>>> correct keys into a second rr_list. I solved this by
replacing each of<br>
>>> these functions by two new ones (thus creating four
functions). All<br>
>>> versions take only 3 arguments and differ in the way
they treat the<br>
>>> good_keys value. One versions name ends with
"_status_only" (e.g.<br>
>>> ldns_verify_rrsig_keylist_notime_status_only) and
this does not report<br>
>>> the good_keys at all, just the result of
verification. The other ends<br>
>>> with "_" (e.g. ldns_verify_rrsig_keylist_notime_) and
returns a tuple<br>
>>> (status, good_keys) where good_keys are indexes of
the keys in the key<br>
>>> list supplied to the function. Thus the whole
business of two rr_lists<br>
>>> sharing the same data is sidestepped.<br>
>>><br>
<br>
> .. and here it ends<br>
<br>
>>> The patches are made for each file separately because
the fixes are<br>
>>> mostly independent. I also included several test
scripts which should<br>
>>> show how the situation was fixed. They either show a
situation where the<br>
>>> old version would crash with a segmentation fault or
display the amount<br>
>>> of memory the app has used thus pointing to a memory
leak. When used<br>
>>> with patched sources, none of the scripts should
crash and none should<br>
>>> report more that ~30MB of memory used.<br>
>>><br>
>>> Best regards<br>
>>><br>
>>> Beda<br>
>>><br>
>>> p.s.- the patch for ldns_rdf.i is in fact not related
to the rest and<br>
>>> fixes and unrelated memory leak in
ldns_rdf.new_frm_str<br>
>>><br>
>>> p.p.s.- I did not touch a related issue of rr and rdf
relationship. In<br>
>>> current version, the rdf data does not live beyond
the lifetime of the<br>
>>> corresponding rr. This is demonstrated in the
attached<br>
>>> test-rrlist-get-rdf.py. The problem could again be
solved by cloning all<br>
>>> rdfs on retrieval and addition from/into an rr.<br>
>>> However, I will wait how the current patch is
received before I start<br>
>>> thinking about fixing it.<br>
>>><br>
>>><br>
>>> On 03/25/2011 09:48 AM, Bedrich Kosata wrote:<br>
>>>> Hi everybody,<br>
>>>><br>
>>>> while trying to find a cause of a memory leak in
a simple script, I<br>
>>>> found a nest of memory related issues in the
python bindings.<br>
>>>> The problems are all related to one common
problem - who takes care of<br>
>>>> memory of composite objects, such as
ldns_rr_lists or ldns_pkt.<br>
>>>> For example, in the current version, ldns_pkt
bindings use ldns_pkt_free<br>
>>>> to free a packet structure, however, when a
rr_list is taken from the<br>
>>>> packet and returned from a function, the packet
gets out of scope, is<br>
>>>> freed and the rr_list refers to already freed
memory.<br>
>>>> On the other hand, a rr_list only frees its own
memory, not memory of<br>
>>>> the stored rrs. This can lead to memory leaks.<br>
>>>> I am attaching two scripts that demonstrate these
problems (it might be<br>
>>>> necessary to have the sources patched with the
"freeing None" patch I<br>
>>>> sent last week).<br>
>>>> I would be willing to have a stab at the problems
(provided I get<br>
>>>> clearance from my boss :)), but the only solution
I think would be clean<br>
>>>> enough, is to clone the necessary bits where
needed. This might lead to<br>
>>>> some inefficiency and slowdowns (probably not
big), so I would like to<br>
>>>> ask if this is ok.<br>
>>>> If there is anyone else willing to fix this, I
would be happy to act as<br>
>>>> a tester.<br>
>>>><br>
>>>> Cheers<br>
>>>><br>
>>>> Beda<br>
>>>><br>
>>>> p.s.- test-pkt-free.py crashes with a
segmentation fault,<br>
>>>> test-rr-list.py ends up eating about 130 MB of
memory and more than<br>
>>>> 400000 python objects which python cannot free.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> ldns-users mailing list<br>
>>>> <a class="moz-txt-link-abbreviated" href="mailto:ldns-users@open.nlnetlabs.nl">ldns-users@open.nlnetlabs.nl</a><br>
>>>>
<a class="moz-txt-link-freetext" href="http://open.nlnetlabs.nl/mailman/listinfo/ldns-users">http://open.nlnetlabs.nl/mailman/listinfo/ldns-users</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> ldns-users mailing list<br>
>>> <a class="moz-txt-link-abbreviated" href="mailto:ldns-users@open.nlnetlabs.nl">ldns-users@open.nlnetlabs.nl</a><br>
>>> <a class="moz-txt-link-freetext" href="http://open.nlnetlabs.nl/mailman/listinfo/ldns-users">http://open.nlnetlabs.nl/mailman/listinfo/ldns-users</a><br>
<br>
</blockquote>
<br>
<span style="white-space: pre;">>
_______________________________________________<br>
> ldns-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:ldns-users@open.nlnetlabs.nl">ldns-users@open.nlnetlabs.nl</a><br>
> <a class="moz-txt-link-freetext" href="http://open.nlnetlabs.nl/mailman/listinfo/ldns-users">http://open.nlnetlabs.nl/mailman/listinfo/ldns-users</a></span><br>
<br>
<br>
</body>
</html>