Re: NSD database memory usage

"W.C.A. Wijngaards" <[email protected]>
Newsgroups gmane.network.dns.nsd.general
Message-ID <[email protected]>
Hi Antti,

On 07/02/18 13:36, Antti Ristimäki wrote:
> Hi Wouter,
> 
> ----- On 6 Feb, 2018, at 16:14, W.C.A. Wijngaards [email protected] wrote:
> 
>> Hi Antti,
>>
>> On 06/02/18 15:08, Antti Ristimäki wrote:
>>> Hi,
>>>
>>> ----- On 6 Feb, 2018, at 15:46, Anand Buddhdev [email protected] wrote:
>>>
>>>> On 06/02/2018 13:58, W.C.A. Wijngaards wrote:
>>>>
>>>>> Hi Antti,
>>>>>
>>>>> It is a memory leak, thank you for the report!  Fixed it, code is copied
>>>>> below and in the code repository.  It happens when unknown RR formatted
>>>>> RRs are read from zonefile.
>>>>
>>>> Hi Wouter, thanks for the quick fix!
>>>>
>>>> So Antti, which unusual RRs do you have in your zone?
>>>
>>> That's something I also wonder, as the zone in question contains only very usual
>>> RRs, mainly delegation NS records. There are quite a lot of IDN names but that
>>> should probably be business as usual.
>>>
>>> I will try to look at the zone contents if I find anything. Wouter, anything
>>> particular in mind that I should be searching for?
>>
>> RRs printed in the \#length hexadecimals format cause the problem that I
>> found.  Regardless if the type was known to NSD, it was the text
>> formatting in the parser that leaked.
>>
>> If the problem is still there (after using patch?) then it maybe
>> possible to reproduce with (a smaller subset of) the zone?
> 
> We rebuilt the package with the patch and unfortunately it seems that the memory usage still increases after each reload like it did before the patch. We'll try to debug this further.

Found the issue and fixed it in the code repository (with offlist
debug).  It was NSEC3 processing and previously I fixed an NSEC signed zone.

Thanks for the report,

Best regards, Wouter

> 
> Antti
>

_______________________________________________
nsd-users mailing list
[email protected]
https://open.nlnetlabs.nl/mailman/listinfo/nsd-users
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7fqj8spObrBWga+On28cLX4EX40FAlp8FNkACgkQn28cLX4E
X43eTxAAgpwmLK6sMKinFMQu3JaXXxWSFov/E5cZMkeIk1O390bTHGYCI2zVpDpB
5bDeMIC7qHToyIrkchJx6w1y9crujQhZnxcZ90VjTSnIWbZ4foqE0gsAl+PXb9UW
IELR+Kgl+x56F7gi/MF/jaC0ff72YdUVDJEUtUofPh2bEuFnhuSu3zuHR8/jdjNC
EwXN2tguJt9lmYg7WZoavlXtsKYX/nzjNHGLokSN+/6ms7orju2KlKTAlReyzjBB
0pmp6B4NZ7JWYkEj8KBkvLaBEZOVIP2tXwpiZysN2DTPKA/kH1KcYYWHPK4hayMW
k2oEiyl8wbCrwdfExBfxepXQad/h2iEqRwVY+FqcBnfVlhh9CoACyGqCC5ps1utz
T30iLcAkM576r74RxFVSsqE6O/WpWoX7yrYEVRDfL3bbyZ1MBjkg3iOaV/I36nGM
KwlLOEQ0EMEZKAtDCTjt3qzU8inQQFLTPD3ZjdrYu/HCspkC04ZHY9Np3l9ej36O
1vxDsgOsyfRtmg5IFEXr3n0vXbe62pfxKaOzvWs8Bv+aSkm+gFSMBO/GzehGrOFG
mY+iGOB8a8st+iZl4ExDKqbwR91N6fljl1drvAJdEl4SpO9rS443D2eUlkL2MqcC
KHbKsCQXby2qUCXQQQdtiiE4x3d/v118Zc9y5aPXKvj5rwYE+Ks=
=QXb3
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.