From jn at stusta.de Tue Aug 6 17:59:32 2013 From: jn at stusta.de (Johannes Naab) Date: Tue, 06 Aug 2013 19:59:32 +0200 Subject: [ldns-users] contrib/python: memory leak in ldns_pkt.new_query Message-ID: <52013984.2030006@stusta.de> Hi, The python wrapper for ldns appears to leak memory when packets are created by ldns_pkt.new_query. The following is a short example (tested in ldns-1.6.16, Python 2.7.5 Linux 3.10, amd64): #!/usr/bin/env python2.7 import ldns dname = ldns.ldns_dname("test.nic.cz") def leak(): pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, ldns.LDNS_RR_CLASS_IN, 0) while True: leak() Root of the problem seems to be, that the pointer to the ldns_pkt struct is not considered owned by the swig wrapper, and thus the pkt struct is not freed upon garbage collection in python. import ldns dname = ldns.ldns_dname("test.nic.cz") pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, ldns.LDNS_RR_CLASS_IN, 0) print pkt.thisown => False. If new_query is replaced by new_query_frm_str the packet is "owned" by the swig wrapper, and the packet does not leak. pkt = ldns.ldns_pkt.new_query_frm_str(str(dname), ldns.LDNS_RR_TYPE_A, ldns.LDNS_RR_CLASS_IN, 0) print pkt.thisown => True I tried to convince swig that the struct should be owned by the wrapper by inserting a "%newobject ldns_pkt_query_new;" below line 44 in contrib/python/ldns_packet.i. This made swig own the pointer, but freeing the packet on garbage collection made python crash (memory corruption, double free). My knowledge and understanding of swig is limited. Johannes From karel.slany at nic.cz Wed Aug 7 09:26:00 2013 From: karel.slany at nic.cz (Karel Slany) Date: Wed, 07 Aug 2013 11:26:00 +0200 Subject: [ldns-users] contrib/python: memory leak in ldns_pkt.new_query In-Reply-To: <52013984.2030006@stusta.de> References: <52013984.2030006@stusta.de> Message-ID: <520212A8.2050601@nic.cz> Hello Johannes, I'll have look at it. K. Am 06.08.2013 19:59, schrieb Johannes Naab: > Hi, > > The python wrapper for ldns appears to leak memory when packets are > created by ldns_pkt.new_query. > > The following is a short example (tested in ldns-1.6.16, Python 2.7.5 > Linux 3.10, amd64): > #!/usr/bin/env python2.7 > import ldns > > dname = ldns.ldns_dname("test.nic.cz") > > def leak(): > pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, > ldns.LDNS_RR_CLASS_IN, 0) > > while True: > leak() > > > Root of the problem seems to be, that the pointer to the ldns_pkt struct > is not considered owned by the swig wrapper, and thus the pkt struct is > not freed upon garbage collection in python. > > import ldns > dname = ldns.ldns_dname("test.nic.cz") > pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, > ldns.LDNS_RR_CLASS_IN, 0) > print pkt.thisown > > => False. > > If new_query is replaced by new_query_frm_str the packet is "owned" by > the swig wrapper, and the packet does not leak. > > > pkt = ldns.ldns_pkt.new_query_frm_str(str(dname), ldns.LDNS_RR_TYPE_A, > ldns.LDNS_RR_CLASS_IN, 0) > print pkt.thisown > > => True > > I tried to convince swig that the struct should be owned by the wrapper > by inserting a "%newobject ldns_pkt_query_new;" below line 44 in > contrib/python/ldns_packet.i. This made swig own the pointer, but > freeing the packet on garbage collection made python crash (memory > corruption, double free). My knowledge and understanding of swig is limited. > > > Johannes > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From karel.slany at nic.cz Wed Aug 7 12:47:39 2013 From: karel.slany at nic.cz (Karel Slany) Date: Wed, 07 Aug 2013 14:47:39 +0200 Subject: [ldns-users] contrib/python: memory leak in ldns_pkt.new_query In-Reply-To: <520212A8.2050601@nic.cz> References: <52013984.2030006@stusta.de> <520212A8.2050601@nic.cz> Message-ID: <520241EB.7050308@nic.cz> Hello, the patch in the attachment solves the memory leak and the owner problem. Someone at NLnet Labs, please, apply the patch onto the ldns svn. Using '%newobject ldns_pkt_query_new;' solved only one half of the problem. Dname has to be cloned before being used in new_query because ldns_pkt_query_new() uses the rr_name pointer directly instead of creating a copy. Double free is the result as the same rr_name object is being destroyed once in dname and second in pkt. The patch creates a new wrapper function that automatically clones the dname rr_name before calling ldns_pkt_query_new(). Best regards, K. Am 07.08.2013 11:26, schrieb Karel Slany: > Hello Johannes, > > I'll have look at it. > > K. > > Am 06.08.2013 19:59, schrieb Johannes Naab: >> Hi, >> >> The python wrapper for ldns appears to leak memory when packets are >> created by ldns_pkt.new_query. >> >> The following is a short example (tested in ldns-1.6.16, Python 2.7.5 >> Linux 3.10, amd64): >> #!/usr/bin/env python2.7 >> import ldns >> >> dname = ldns.ldns_dname("test.nic.cz") >> >> def leak(): >> pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, >> ldns.LDNS_RR_CLASS_IN, 0) >> >> while True: >> leak() >> >> >> Root of the problem seems to be, that the pointer to the ldns_pkt struct >> is not considered owned by the swig wrapper, and thus the pkt struct is >> not freed upon garbage collection in python. >> >> import ldns >> dname = ldns.ldns_dname("test.nic.cz") >> pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, >> ldns.LDNS_RR_CLASS_IN, 0) >> print pkt.thisown >> >> => False. >> >> If new_query is replaced by new_query_frm_str the packet is "owned" by >> the swig wrapper, and the packet does not leak. >> >> >> pkt = ldns.ldns_pkt.new_query_frm_str(str(dname), ldns.LDNS_RR_TYPE_A, >> ldns.LDNS_RR_CLASS_IN, 0) >> print pkt.thisown >> >> => True >> >> I tried to convince swig that the struct should be owned by the wrapper >> by inserting a "%newobject ldns_pkt_query_new;" below line 44 in >> contrib/python/ldns_packet.i. This made swig own the pointer, but >> freeing the packet on garbage collection made python crash (memory >> corruption, double free). My knowledge and understanding of swig is limited. >> >> >> Johannes >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -------------- next part -------------- Index: trunk/contrib/python/ldns_packet.i =================================================================== --- trunk/contrib/python/ldns_packet.i (revision 3860) +++ trunk/contrib/python/ldns_packet.i (working copy) @@ -109,6 +109,18 @@ /* clone data when pushed in */ +%newobject _ldns_pkt_query_new; +%rename (__ldns_pkt_query_new) ldns_pkt_query_new; +%inline +%{ + ldns_pkt * _ldns_pkt_query_new(ldns_rdf *rr_name, ldns_rr_type rr_type, + ldns_rr_class rr_class, uint16_t flags) + { + return ldns_pkt_query_new(ldns_rdf_clone(rr_name), rr_type, rr_class, + flags); + } +%} + %rename(__ldns_pkt_push_rr) ldns_pkt_push_rr; %inline %{ bool _ldns_pkt_push_rr(ldns_pkt* p, ldns_pkt_section sec, ldns_rr *rr) { @@ -170,7 +182,7 @@ :param flags: packet flags :returns: new ldns_pkt object """ - return _ldns.ldns_pkt_query_new(rr_name, rr_type, rr_class, flags) + return _ldns._ldns_pkt_query_new(rr_name, rr_type, rr_class, flags) @staticmethod def new_query_frm_str(rr_name, rr_type, rr_class, flags, raiseException = True): From jn at stusta.de Wed Aug 7 13:39:46 2013 From: jn at stusta.de (Johannes Naab) Date: Wed, 07 Aug 2013 15:39:46 +0200 Subject: [ldns-users] contrib/python: memory leak in ldns_pkt.new_query In-Reply-To: <520241EB.7050308@nic.cz> References: <52013984.2030006@stusta.de> <520212A8.2050601@nic.cz> <520241EB.7050308@nic.cz> Message-ID: <52024E22.5080404@stusta.de> Hi, the patch works well for me. Thank you for the fast response, the patch and the explanation. Johannes On 08/07/2013 02:47 PM, Karel Slany wrote: > Hello, > > the patch in the attachment solves the memory leak and the owner problem. > > Someone at NLnet Labs, please, apply the patch onto the ldns svn. > > > Using '%newobject ldns_pkt_query_new;' solved only one half of the > problem. Dname has to be cloned before being used in new_query because > ldns_pkt_query_new() uses the rr_name pointer directly instead of > creating a copy. Double free is the result as the same rr_name object is > being destroyed once in dname and second in pkt. > > The patch creates a new wrapper function that automatically clones the > dname rr_name before calling ldns_pkt_query_new(). > > Best regards, > K. > > Am 07.08.2013 11:26, schrieb Karel Slany: >> Hello Johannes, >> >> I'll have look at it. >> >> K. >> >> Am 06.08.2013 19:59, schrieb Johannes Naab: >>> Hi, >>> >>> The python wrapper for ldns appears to leak memory when packets are >>> created by ldns_pkt.new_query. >>> >>> The following is a short example (tested in ldns-1.6.16, Python 2.7.5 >>> Linux 3.10, amd64): >>> #!/usr/bin/env python2.7 >>> import ldns >>> >>> dname = ldns.ldns_dname("test.nic.cz") >>> >>> def leak(): >>> pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, >>> ldns.LDNS_RR_CLASS_IN, 0) >>> >>> while True: >>> leak() >>> >>> >>> Root of the problem seems to be, that the pointer to the ldns_pkt struct >>> is not considered owned by the swig wrapper, and thus the pkt struct is >>> not freed upon garbage collection in python. >>> >>> import ldns >>> dname = ldns.ldns_dname("test.nic.cz") >>> pkt = ldns.ldns_pkt.new_query(dname, ldns.LDNS_RR_TYPE_A, >>> ldns.LDNS_RR_CLASS_IN, 0) >>> print pkt.thisown >>> >>> => False. >>> >>> If new_query is replaced by new_query_frm_str the packet is "owned" by >>> the swig wrapper, and the packet does not leak. >>> >>> >>> pkt = ldns.ldns_pkt.new_query_frm_str(str(dname), ldns.LDNS_RR_TYPE_A, >>> ldns.LDNS_RR_CLASS_IN, 0) >>> print pkt.thisown >>> >>> => True >>> >>> I tried to convince swig that the struct should be owned by the wrapper >>> by inserting a "%newobject ldns_pkt_query_new;" below line 44 in >>> contrib/python/ldns_packet.i. This made swig own the pointer, but >>> freeing the packet on garbage collection made python crash (memory >>> corruption, double free). My knowledge and understanding of swig is limited. >>> >>> >>> Johannes >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > -- From erik.ostlyngen at uninett.no Thu Aug 8 08:04:03 2013 From: erik.ostlyngen at uninett.no (Erik P. Ostlyngen) Date: Thu, 08 Aug 2013 10:04:03 +0200 Subject: [ldns-users] problem reading broken zonefile, possibly a memory bug Message-ID: <520350F3.9070805@uninett.no> Hi, When I try to read a broken zonefile with ldns, the function ldns_zone_new_frm_fp_l aborts in a way that might indicate some buggy memory handling. I'm using ldns-1.6.16 on a Linux 3.2.0, 64 bit x86 SMP (Ubuntu 12.04). The library was configured and built with default settings. My broken zonefile looks like this: $TTL 4500 $ORIGIN broken.org. myzone.org. 1000 IN SOA ( ldns.myzone.org. ns.ldns.myzone.org. 2012113030 12345 1827 2345678 87654 hei hei hei hei (... last line repeated 4000 times) Note that a ')' is missing at the end of the SOA record. Output from the example program ldns-read-zone: ldns_download/ldns-1.6.16/examples$ ./ldns-read-zone broken.org *** glibc detected *** /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone: double free or corruption (!prev): 0x000000000238a290 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f60d4c09b96] /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1(ldns_rr_new_frm_fp_l+0x160)[0x7f60d4f83d20] /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1(ldns_zone_new_frm_fp_l+0xb8)[0x7f60d4f8c638] /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone[0x40145a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f60d4bac76d] /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone[0x401781] ======= Memory map: ======== 00400000-00403000 r-xp 00000000 fc:00 675055 /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone 00602000-00603000 r--p 00002000 fc:00 675055 /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone 00603000-00604000 rw-p 00003000 fc:00 675055 /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone 0238a000-023ab000 rw-p 00000000 00:00 0 [heap] 7f60d4192000-7f60d41a7000 r-xp 00000000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d41a7000-7f60d43a6000 ---p 00015000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d43a6000-7f60d43a7000 r--p 00014000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d43a7000-7f60d43a8000 rw-p 00015000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d43a8000-7f60d43be000 r-xp 00000000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d43be000-7f60d45bd000 ---p 00016000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d45bd000-7f60d45be000 r--p 00015000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d45be000-7f60d45bf000 rw-p 00016000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d45bf000-7f60d45c1000 r-xp 00000000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d45c1000-7f60d47c1000 ---p 00002000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d47c1000-7f60d47c2000 r--p 00002000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d47c2000-7f60d47c3000 rw-p 00003000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d47c3000-7f60d4962000 r-xp 00000000 fc:00 408958 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4962000-7f60d4b61000 ---p 0019f000 fc:00 408958 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b61000-7f60d4b7c000 r--p 0019e000 fc:00 408958 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b7c000-7f60d4b87000 rw-p 001b9000 fc:00 408958 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b87000-7f60d4b8b000 rw-p 00000000 00:00 0 7f60d4b8b000-7f60d4d40000 r-xp 00000000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4d40000-7f60d4f3f000 ---p 001b5000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4f3f000-7f60d4f43000 r--p 001b4000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4f43000-7f60d4f45000 rw-p 001b8000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4f45000-7f60d4f4a000 rw-p 00000000 00:00 0 7f60d4f4a000-7f60d4f9c000 r-xp 00000000 fc:00 528909 /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 7f60d4f9c000-7f60d519b000 ---p 00052000 fc:00 528909 /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 7f60d519b000-7f60d519c000 r--p 00051000 fc:00 528909 /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 7f60d519c000-7f60d51a2000 rw-p 00052000 fc:00 528909 /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 7f60d51a2000-7f60d51c4000 r-xp 00000000 fc:00 391112 /lib/x86_64-linux-gnu/ld-2.15.so 7f60d53b7000-7f60d53bb000 rw-p 00000000 00:00 0 7f60d53c0000-7f60d53c4000 rw-p 00000000 00:00 0 7f60d53c4000-7f60d53c5000 r--p 00022000 fc:00 391112 /lib/x86_64-linux-gnu/ld-2.15.so 7f60d53c5000-7f60d53c7000 rw-p 00023000 fc:00 391112 /lib/x86_64-linux-gnu/ld-2.15.so 7fff6e0ce000-7fff6e0ef000 rw-p 00000000 00:00 0 [stack] 7fff6e0ef000-7fff6e0f0000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted Regards, Erik ?stlyngen UNINETT Norid From wouter at nlnetlabs.nl Thu Aug 8 12:37:07 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 08 Aug 2013 14:37:07 +0200 Subject: [ldns-users] contrib/python: memory leak in ldns_pkt.new_query In-Reply-To: <52024E22.5080404@stusta.de> References: <52013984.2030006@stusta.de> <520212A8.2050601@nic.cz> <520241EB.7050308@nic.cz> <52024E22.5080404@stusta.de> Message-ID: <520390F3.1050209@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karel, Patch applied, thanks! Best regards, Wouter On 08/07/2013 03:39 PM, Johannes Naab wrote: > Hi, > > the patch works well for me. Thank you for the fast response, the > patch and the explanation. > > Johannes > > On 08/07/2013 02:47 PM, Karel Slany wrote: >> Hello, >> >> the patch in the attachment solves the memory leak and the owner >> problem. >> >> Someone at NLnet Labs, please, apply the patch onto the ldns >> svn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSA5DzAAoJEJ9vHC1+BF+NJR4P/3ZazsrvY/2d8v7VZ4or58Cb jRWaWJz3YsN1o4gD3U2Esq+Rc5SiX612/rppD5bbYkcwi12aC92aSdKB8Jb+H8jR 4ao3xSYaowNGZvxdcfBBDP2lApGfiL8YQ+KU8aTKFkMIoyM4Br8Cu3wmx+HlZF7+ FGrwPG42m6lkEvIMHgQ8rwFJu+rSwWnBmH1he0mXkAxn46SbNCHTVGevIQ79Tv8B zroOcN82iNIJNt/u/QPIQiR5o1hTS8/e/aIxCxJl2j+akA9Z+wxbMokcTbX8SkPh kddO2Exm+Xx6lWj8C0qStYNeAH0wPkkLP6m8nM9aI+MJtP2ErpNRP8cP3Eznm1d7 koRmhRrrZ097ZsRMqFvoWEvwYAVniBS7B3K8gq4ZTcJGyEbdXoMaP4LSBRmnPD3v Glm7cJCNeI/Vpx8Aoxy47CnsaVeZJNYgLRsM/1rtmT13ETYd1MuL+GSFE+8FClND 5UTvW1tmy9b3+fSRD4cWKAr+ZZIeL6u35Coy0GPGVEQ3PsF6pUMjlFIUzfeA76Bl iLgzW0KrNoPx2Ddni9mr4RxbKsrWdKpnf1zubSKTM03alo05lc/EFyAznwVOUcIZ EGIs03EwjPyH7dxg7Xpp53wYN17GwzfLPg9VoNVXeqFxzFB4WFxcRk7Gjia/k1ig tCXfgGkC+2lsEBEh+A/Y =VR/h -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Fri Aug 9 09:36:30 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Fri, 09 Aug 2013 11:36:30 +0200 Subject: [ldns-users] problem reading broken zonefile, possibly a memory bug In-Reply-To: <520350F3.9070805@uninett.no> References: <520350F3.9070805@uninett.no> Message-ID: <5204B81E.1070108@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Erik, On 08/08/2013 10:04 AM, Erik P. Ostlyngen wrote: > Hi, > > When I try to read a broken zonefile with ldns, the function > ldns_zone_new_frm_fp_l aborts in a way that might indicate some > buggy memory handling. I'm using ldns-1.6.16 on a Linux 3.2.0, 64 > bit x86 SMP (Ubuntu 12.04). The library was configured and built > with default settings. Fixed this in git in parse.c, the end-of-buffer check was wrong. Best regards, Wouter > My broken zonefile looks like this: $TTL 4500 $ORIGIN broken.org. > > myzone.org. 1000 IN SOA ( ldns.myzone.org. ns.ldns.myzone.org. > 2012113030 12345 1827 2345678 87654 > > hei hei hei hei (... last line repeated 4000 times) > > Note that a ')' is missing at the end of the SOA record. Output > from the example program ldns-read-zone: > > ldns_download/ldns-1.6.16/examples$ ./ldns-read-zone broken.org *** > glibc detected *** > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone: > > double free or corruption (!prev): 0x000000000238a290 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f60d4c09b96] > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1(ldns_rr_new_frm_fp_l+0x160)[0x7f60d4f83d20] > > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1(ldns_zone_new_frm_fp_l+0xb8)[0x7f60d4f8c638] > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone[0x40145a] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f60d4bac76d] > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone[0x401781] > > ======= Memory map: ======== > 00400000-00403000 r-xp 00000000 fc:00 675055 > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone > > 00602000-00603000 r--p 00002000 fc:00 675055 > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone > > 00603000-00604000 rw-p 00003000 fc:00 675055 > /home/erik/ldns_download/ldns-1.6.16/examples/.libs/lt-ldns-read-zone > > 0238a000-023ab000 rw-p 00000000 00:00 0 > [heap] 7f60d4192000-7f60d41a7000 r-xp 00000000 fc:00 390968 > /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d41a7000-7f60d43a6000 ---p > 00015000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f60d43a6000-7f60d43a7000 r--p 00014000 fc:00 390968 > /lib/x86_64-linux-gnu/libgcc_s.so.1 7f60d43a7000-7f60d43a8000 rw-p > 00015000 fc:00 390968 /lib/x86_64-linux-gnu/libgcc_s.so.1 > 7f60d43a8000-7f60d43be000 r-xp 00000000 fc:00 391143 > /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d43be000-7f60d45bd000 > ---p 00016000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 > 7f60d45bd000-7f60d45be000 r--p 00015000 fc:00 391143 > /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f60d45be000-7f60d45bf000 > rw-p 00016000 fc:00 391143 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 > 7f60d45bf000-7f60d45c1000 r-xp 00000000 fc:00 391094 > /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d45c1000-7f60d47c1000 ---p > 00002000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so > 7f60d47c1000-7f60d47c2000 r--p 00002000 fc:00 391094 > /lib/x86_64-linux-gnu/libdl-2.15.so 7f60d47c2000-7f60d47c3000 rw-p > 00003000 fc:00 391094 /lib/x86_64-linux-gnu/libdl-2.15.so > 7f60d47c3000-7f60d4962000 r-xp 00000000 fc:00 408958 > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4962000-7f60d4b61000 > ---p 0019f000 fc:00 408958 > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b61000-7f60d4b7c000 > r--p 0019e000 fc:00 408958 > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b7c000-7f60d4b87000 > rw-p 001b9000 fc:00 408958 > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7f60d4b87000-7f60d4b8b000 > rw-p 00000000 00:00 0 7f60d4b8b000-7f60d4d40000 r-xp 00000000 fc:00 > 391095 /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4d40000-7f60d4f3f000 > ---p 001b5000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so > 7f60d4f3f000-7f60d4f43000 r--p 001b4000 fc:00 391095 > /lib/x86_64-linux-gnu/libc-2.15.so 7f60d4f43000-7f60d4f45000 rw-p > 001b8000 fc:00 391095 /lib/x86_64-linux-gnu/libc-2.15.so > 7f60d4f45000-7f60d4f4a000 rw-p 00000000 00:00 0 > 7f60d4f4a000-7f60d4f9c000 r-xp 00000000 fc:00 528909 > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 > 7f60d4f9c000-7f60d519b000 ---p 00052000 fc:00 528909 > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 > 7f60d519b000-7f60d519c000 r--p 00051000 fc:00 528909 > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 > 7f60d519c000-7f60d51a2000 rw-p 00052000 fc:00 528909 > /home/erik/ldns_download/ldns-1.6.16/.libs/libldns.so.1.6.16 > 7f60d51a2000-7f60d51c4000 r-xp 00000000 fc:00 391112 > /lib/x86_64-linux-gnu/ld-2.15.so 7f60d53b7000-7f60d53bb000 rw-p > 00000000 00:00 0 7f60d53c0000-7f60d53c4000 rw-p 00000000 00:00 0 > 7f60d53c4000-7f60d53c5000 r--p 00022000 fc:00 391112 > /lib/x86_64-linux-gnu/ld-2.15.so 7f60d53c5000-7f60d53c7000 rw-p > 00023000 fc:00 391112 /lib/x86_64-linux-gnu/ld-2.15.so > 7fff6e0ce000-7fff6e0ef000 rw-p 00000000 00:00 0 [stack] > 7fff6e0ef000-7fff6e0f0000 r-xp 00000000 00:00 0 [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] > Aborted > > > Regards, Erik ?stlyngen UNINETT Norid > _______________________________________________ ldns-users mailing > list ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSBLgeAAoJEJ9vHC1+BF+NR3sP/1tnWkxWiSgANEUTmjnrW8HN jEQS71et6LlFagDNZ7nZet8nw6l0atpjqXk3y5C8CjMf6U656TJI376LPdEBlP8F 8Dnd2taZH1ZGG/4So3t8n4lLPXiOJcAyv9UIG6G3802XosPW8GohFGJCPNfjltFy saou92wjD58O/Why1u0rLgSizaSvUSkKBzLxX1ABWdekhJKuRbEDHExuyix0qb8d t4hUInMJCDX7ITs8CEEjfjSDrDxIXLDuk622BCTlL66I1YKcfFmmWPoJgnA/wZ4R Y9T8OR+mRyr5m1YHFwDGdDW6fYGP7ypvlWIvsQJG4JQEWGrX4zDFpbmQ05ODAd7O /UGGLzigS4O/rXfyaMHIFVPTMOx4TaedXHn8DoUcKHFwyhhjhiIHJskVGc0eLuTF iQoxw4p8wWQNywbmkgWawLf8wZh8OA23bvFf9nJjsI16SyQ9SVe+PkqLV9aOwuGR OGfjerFh2lsf3ALKaHThNfqnzcFN966hKIdlJeyvXRCc56sHImUSNKoe4lOUKh2k YfhAfJeL0fFRpiaWSuTWB2ioiJzX3UPr7c6vHF1mYL4zvOqn/76QOts5CdrC7wQL PlFVm0hyaZHGUp4pynrWz8KTsX4rMCjhlFknWr1BISIY29UWuv8CoQYoz2g6kYlE UTt2KLtAVxwY6u75Q2S1 =zxHN -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu Aug 15 12:24:33 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 15 Aug 2013 14:24:33 +0200 Subject: [ldns-users] ldns moved to git Message-ID: <520CC881.30003@nlnetlabs.nl> Dear All, ldns development moved away from subversion and is now maintained in a git repository. To retrieve a local copy of the development tree do: git clone https://git.nlnetlabs.nl/ldns/ This url uses a cacert.org certificate. Alternatively the repository can also be cloned with: git clone git://git.nlnetlabs.nl/ldns/ or git clone http://git.nlnetlabs.nl/ldns/ The repository can be explored using a web-browser as well at: https://git.nlnetlabs.nl/ldns/ Best regards, -- Willem From paul at nohats.ca Thu Aug 15 13:28:56 2013 From: paul at nohats.ca (Paul Wouters) Date: Thu, 15 Aug 2013 09:28:56 -0400 (EDT) Subject: [ldns-users] ldns moved to git In-Reply-To: <520CC881.30003@nlnetlabs.nl> References: <520CC881.30003@nlnetlabs.nl> Message-ID: On Thu, 15 Aug 2013, Willem Toorop wrote: > ldns development moved away from subversion and is now maintained in a > git repository. To retrieve a local copy of the development tree do: > > git clone https://git.nlnetlabs.nl/ldns/ Great!! Thank you for switching to git! It will make live much easier for everyone :) Although: git clone https://git.nlnetlabs.nl/ldns/ Cloning into 'ldns'... fatal: unable to access 'https://git.nlnetlabs.nl/ldns/': The certificate was signed using a signature algorithm that is disabled because it is not secure. firefox tells me the same. Paul From willem at nlnetlabs.nl Thu Aug 15 13:39:58 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 15 Aug 2013 15:39:58 +0200 Subject: [ldns-users] ldns moved to git In-Reply-To: References: <520CC881.30003@nlnetlabs.nl> Message-ID: <520CDA2E.4020601@nlnetlabs.nl> Op 15-08-13 15:28, Paul Wouters schreef: > fatal: unable to access 'https://git.nlnetlabs.nl/ldns/': The > certificate was signed using a signature algorithm that is disabled > because it is not secure.\ Ah... I accidentally configured an old cacert intermediate (class3) certificate. It is fixed now. -- Willem From gagandeep902 at gmail.com Mon Aug 19 09:34:29 2013 From: gagandeep902 at gmail.com (Gagandeep Singh Panesar) Date: Mon, 19 Aug 2013 15:04:29 +0530 Subject: [ldns-users] new to ldns Message-ID: Hi, I am new to ldns libraries. I am interested in makin a DNS Server using ldns libraries, so how should I start with that..? Regards, Gagandeep Singh Panesar -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmens.dns at gmail.com Mon Aug 19 09:55:39 2013 From: jpmens.dns at gmail.com (Jan-Piet Mens) Date: Mon, 19 Aug 2013 11:55:39 +0200 Subject: [ldns-users] new to ldns In-Reply-To: References: Message-ID: <20130819095539.GA99515@tiggr.ww.mens.de> > I am new to ldns libraries. I am interested in makin a DNS Server using > ldns libraries, so how should I start with that..? Use Unbound? [1]. -JP [1]: http://unbound.net From ondrej at sury.org Tue Aug 20 12:12:48 2013 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 20 Aug 2013 14:12:48 +0200 Subject: [ldns-users] new to ldns In-Reply-To: References: Message-ID: On Mon, Aug 19, 2013 at 11:34 AM, Gagandeep Singh Panesar < gagandeep902 at gmail.com> wrote: > Hi, > I am new to ldns libraries. I am interested in makin a DNS Server using > ldns libraries, so how should I start with that..? > You should probably explain your motivation, since writing a DNS Server is by no means an easy task. O. -- ?Ond?ej Sur? Have you tried Knot DNS ? https://www.knot-dns.cz/ ? a high-performance authoritative-only DNS server -------------- next part -------------- An HTML attachment was scrubbed... URL: From he at uninett.no Wed Aug 21 07:03:25 2013 From: he at uninett.no (Havard Eidnes) Date: Wed, 21 Aug 2013 09:03:25 +0200 (CEST) Subject: [ldns-users] drill: finding child zone? Message-ID: <20130821.090325.24454121.he@uninett.no> Hi, I'm dipping my toe into DNSSEC, and it seems that when drill is used in "top-down" mode, and you do not have a delegation point at every possible point along the name tree, drill will incorrectly conclude that the queried-for name doesn't exist. Example: % drill -TD 2.2.156.193.in-addr.arpa. ptr ends in ;; Domain: 156.193.in-addr.arpa. [T] 156.193.in-addr.arpa. 3600 IN DNSKEY 256 3 8 ;{id = 47623 (zsk), size = 1024b} 156.193.in-addr.arpa. 3600 IN DNSKEY 257 3 8 ;{id = 37642 (ksk), size = 2048b} [T] Existence denied: 2.156.193.in-addr.arpa. DS ;; No ds record for delegation [T] Existence denied: 2.156.193.in-addr.arpa. NS The 2.2.156.193.in-addr.arpa. ptr is registered directly in the 156.193.in-addr.arpa zone, so the registration spans two labels, and there is no delegation at 2.156.193.in-addr.arpa (which drill correctly has concluded). This sort of setup will, I suspect, be much more prevalent in ip6.arpa zones. Bug or feature? Regards, - H?vard From willem at nlnetlabs.nl Wed Aug 21 10:29:02 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 21 Aug 2013 12:29:02 +0200 Subject: [ldns-users] new to ldns In-Reply-To: References: Message-ID: <5214966E.70709@nlnetlabs.nl> Hi Gagandeep, ?Ond?ej is right, it would be helpful if you tell a bit more about the kind of name server you wish to create. That said, ldns might be appropriate for small and simple nameservers that do something peculiar (and are not for production purposes). Within the examples section of the ldns source code is a simple fake nameserver tool for testing and debugging: ldns-testns. We use it in unbounds unit tests and also in experimental setups (for example in our Path MTU black-holes research). You could study its source to get you started. -- Willem Op 20-08-13 14:12, Ond?ej Sur? schreef: > On Mon, Aug 19, 2013 at 11:34 AM, Gagandeep Singh Panesar > > wrote: > > Hi, > I am new to ldns libraries. I am interested in makin a DNS Server > using ldns libraries, so how should I start with that..? > > > You should probably explain your motivation, since writing a DNS Server > is by no means an easy task. > > O. > -- > ?Ond?ej Sur? > > Have you tried Knot DNS ? https://www.knot-dns.cz/ > ? a high-performance authoritative-only DNS server > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From willem at nlnetlabs.nl Wed Aug 21 10:38:37 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 21 Aug 2013 12:38:37 +0200 Subject: [ldns-users] drill: finding child zone? In-Reply-To: <20130821.090325.24454121.he@uninett.no> References: <20130821.090325.24454121.he@uninett.no> Message-ID: <521498AD.3040008@nlnetlabs.nl> Hi H?vard, Op 21-08-13 09:03, Havard Eidnes schreef: > I'm dipping my toe into DNSSEC, and it seems that when drill is > used in "top-down" mode, and you do not have a delegation point > at every possible point along the name tree, drill will > incorrectly conclude that the queried-for name doesn't exist. > > Bug or feature? Bug! I've submitted a bug report: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=521 -- Willem From iwbl5o at nottheoilrig.com Wed Aug 21 23:13:42 2013 From: iwbl5o at nottheoilrig.com (Jack Bates) Date: Wed, 21 Aug 2013 16:13:42 -0700 Subject: [ldns-users] Python rdf.data() Message-ID: <521549A6.7030809@nottheoilrig.com> I am working with the Python wrapper for ldns. rdf.data() returns something like and rdf.size() returns the number of bytes. How do I read the bytes? Thanks! From willem at nlnetlabs.nl Thu Aug 22 08:56:53 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 22 Aug 2013 10:56:53 +0200 Subject: [ldns-users] Python rdf.data() In-Reply-To: <521549A6.7030809@nottheoilrig.com> References: <521549A6.7030809@nottheoilrig.com> Message-ID: <5215D255.4090009@nlnetlabs.nl> Hi Jack, I suspect raw access is not supported by pyldns. Karel, could shed some light on this? -- Willem Op 22-08-13 01:13, Jack Bates schreef: > I am working with the Python wrapper for ldns. > > rdf.data() returns something like > > > and rdf.size() returns the number of bytes. How do I read the bytes? > > Thanks! > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From karel.slany at nic.cz Thu Aug 22 12:31:17 2013 From: karel.slany at nic.cz (Karel Slany) Date: Thu, 22 Aug 2013 14:31:17 +0200 Subject: [ldns-users] Python rdf.data() In-Reply-To: <5215D255.4090009@nlnetlabs.nl> References: <521549A6.7030809@nottheoilrig.com> <5215D255.4090009@nlnetlabs.nl> Message-ID: <52160495.7010009@nic.cz> Greetings, Python's ldns_rdf.data() creates a thin wrapper around the ldns C function ldns_rdf_data(). Function ldns_rdf_data() returns a pointer to an internal data field of the manipulated rdf. Actually, I don't know the actual reason why you are trying to access this low level structures. Manipulating them from Python can be tricky as you can easily end up with corrupted memory. In order to meet your desire I can add a new method ldns_rdf.data_str() which would return a Python string containing copy of the rdf data field. However, in Python3 this would be error-prone, because Python3 uses unicode strings. At the moment I cannot guess, whether the approach would be reliabe in Python3. Please give more information about the reason why you want to use ldns_rdf.data(). Perhaps we could think of a more convenient solution. K. Am 22.08.2013 10:56, schrieb Willem Toorop: > Hi Jack, > > I suspect raw access is not supported by pyldns. > Karel, could shed some light on this? > > -- Willem > > Op 22-08-13 01:13, Jack Bates schreef: >> I am working with the Python wrapper for ldns. >> >> rdf.data() returns something like >> >> >> and rdf.size() returns the number of bytes. How do I read the bytes? >> >> Thanks! >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From karel.slany at nic.cz Thu Aug 22 14:12:25 2013 From: karel.slany at nic.cz (Karel Slany) Date: Thu, 22 Aug 2013 16:12:25 +0200 Subject: [ldns-users] another set of pyldns patches Message-ID: <52161C49.3090301@nic.cz> Hello Wouter and Willem, I'm sending additional set of pyldns pathes. Actually I sent a similar set of patches to Wouter in the end of June. Due to some reason he has not applied them. Never mind, here there are again. 0001) Sets contrib/python/examples/test_rr.py to be executable. 0002) Fixes some test which I am using to check basic functionality of PyLDNS. 0003) Adds an explicit type check in ldns_rdf.reverse() in order to prevent irrecoverable assertion failures. I've tested the changes in Python 2.7 and 3.2 and everything works well. Best regards, K. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PyLDNS-Marked-contrib-python-examples-test_rr.py-exe.patch Type: text/x-patch Size: 523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-PyLDNS-Fixed-type-checks-for-return-values-in-test-s.patch Type: text/x-patch Size: 7852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-PyLDNS-Added-explicit-rdf-type-check-in-ldns_rdf.rev.patch Type: text/x-patch Size: 2485 bytes Desc: not available URL: From wouter at nlnetlabs.nl Thu Aug 22 14:32:10 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 22 Aug 2013 16:32:10 +0200 Subject: [ldns-users] another set of pyldns patches In-Reply-To: <52161C49.3090301@nic.cz> References: <52161C49.3090301@nic.cz> Message-ID: <521620EA.4000809@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi Karel, On 08/22/2013 04:12 PM, Karel Slany wrote: > Hello Wouter and Willem, > > I'm sending additional set of pyldns pathes. Actually I sent a > similar set of patches to Wouter in the end of June. Due to some > reason he has not applied them. Never mind, here there are again. I tried to apply them, but somehow this has not happened. Did I try to use svn or I did not 'git push'? Not sure, but I have committed them again (and thank you for checking). > 0001) Sets contrib/python/examples/test_rr.py to be executable. > 0002) Fixes some test which I am using to check basic functionality > of PyLDNS. 0003) Adds an explicit type check in ldns_rdf.reverse() > in order to prevent irrecoverable assertion failures. > > I've tested the changes in Python 2.7 and 3.2 and everything works > well. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFiDqAAoJEJ9vHC1+BF+NyvoP/iln+6+qOgTFMKl7mAwCzoxm jFR9stm2+9kM4J3q4FxAUIRm7I7U7xhmzlieJDUdbzTr9q1yGYoK4SEY0vTGF4Mi 2FmpsbtrIV3wdj9JQKBt2TncWYLnWgWsSDdd98ov6jVekGJDNlrlnym1HD0y4czp Gfvceku1lf2p5HZlm+PkR+59FFWj9ZvB/BGmpiE46p3XJMyTl8AXbtBrfEG/c6eN BGqlQOIekrwhA3NIqFUFbePLRxQ0Zt6lq1j51qNM+RuOaOuvOPCrFzTmautGHEGV yYeJJK9+5c17twnJAYO8Wif/VmmsEl2C6mmcFPx6eH3uTc3km/W3AXqnpkSLnWQm CuWmjJ44RbEVxA8TgDOIdvlNRF/8udkpChp1iYjK26/5HNwC6MhpQdpLeqNlM1Ac PePk9hf7r8U1Ak5FzarX9ShPfOuxZxO96Bky2i94ZGntjwpKrDwZ9uFYRjjXy4Wp rn7o7PtB555ZYepDrmjci2fTWunK1iKkm0UXvAUVW/sOiX//Hvip0WfG1FQZlAu2 HxUX8M2L60zwRJLzQM7cGU09TjTJTk+aGAkYgpcQsJdady+I5iJbnj4UXhsltFRc EuUiNO4V0h88J0c7hqzm/jch+uyQlXWNFj/NNseX8iHtqfT63sdhRUg3rLcIP5GF 4Pt3Ph8SvdqEtd99esmQ =laDK -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu Aug 22 14:51:18 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 22 Aug 2013 16:51:18 +0200 Subject: [ldns-users] another set of pyldns patches In-Reply-To: <521620EA.4000809@nlnetlabs.nl> References: <52161C49.3090301@nic.cz> <521620EA.4000809@nlnetlabs.nl> Message-ID: <52162566.7090708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am the culprit, I'm afraid. Wouter forwarded your message to me, and I forgot about it or suffered some other form of black-out ;/ but in any case did not commit your patches. Mea culpa. - -- Willem Op 22-08-13 16:32, W.C.A. Wijngaards schreef: > Hoi Karel, > > On 08/22/2013 04:12 PM, Karel Slany wrote: >> Hello Wouter and Willem, > >> I'm sending additional set of pyldns pathes. Actually I sent a >> similar set of patches to Wouter in the end of June. Due to some >> reason he has not applied them. Never mind, here there are >> again. > > I tried to apply them, but somehow this has not happened. Did I > try to use svn or I did not 'git push'? Not sure, but I have > committed them again (and thank you for checking). > >> 0001) Sets contrib/python/examples/test_rr.py to be executable. >> 0002) Fixes some test which I am using to check basic >> functionality of PyLDNS. 0003) Adds an explicit type check in >> ldns_rdf.reverse() in order to prevent irrecoverable assertion >> failures. > >> I've tested the changes in Python 2.7 and 3.2 and everything >> works well. > > Best regards, Wouter > > > _______________________________________________ ldns-users mailing > list ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFiVmAAoJEOX4+CEvd6SYVqYP/1dlD5WbW6MYcZASImyaV+nW yVkrakrjMPWU5Gy9bT74vjhsPMNXpGSH6L0fQGcquTOaJHl9ZLFVTajAInrWvd9O RvAXZjx8YUD1z7yAxt2yNz+zNvc2KBstqoWUf3KAfMQ7p0fCXzIw6PsH0bRJBlwZ 6P3TfMntYsaVgY6p48zl6AL+FyAoJA9wa0D5Z08Mxh+cgHvGbmtDoxlfnWr3w7A/ 2D/JDCukFvrtbvzJnCM1y6trBuc96N1fzU41cP/wXwOMibqgIeQepH429BkI8/wP B8gvdt6hX8kvRIt+qEmxlyWMLVZ+F5R7dB/SJB939qxLy7eXWZIhlADeGQov24Wp d2uzhMvFnrA2Mps9kPaeOmrNlOS1lE3DzBd0gjsHoEdCEbmmd5wu1Vp7SCqcS75k /6bH2gbHINptgzIr5BWNzWoeD3oX93Eqs2qnjotrjBXZ4XXM+hE8xrWKGqYxRjPZ wFxNugs1CV89hqvFBZG0jSdDJhSe1x5EPokJdGWc1447L431Zb/c0B5mdKBQIXO5 tHuALk+F6oU8woTRfvkWKdNIWuBRaf66AcwgplpL++UjLWmaQFkxwr2K+6i+A5o3 iXEwSkJpXrIBlfanLA0Ap+Nruv4QN1quOJUDWPUKzLWKeEYCJ48o2HT4mbrwLGpU uh61eZh4U+hfGUrDHe8C =xUvL -----END PGP SIGNATURE----- From karel.slany at nic.cz Mon Aug 26 14:12:25 2013 From: karel.slany at nic.cz (Karel Slany) Date: Mon, 26 Aug 2013 16:12:25 +0200 Subject: [ldns-users] pyldns patches Message-ID: <521B6249.5070406@nic.cz> Hello Wouter and Willem, I've created another set of patches. This time it fixes issues which I've encountered in ldns_pkt class. There are two files in the attachment: 0001) * Adds necessary cloning of member structures in several wrapper methods in order to prevent double free issues, * adds new method ldns_pkt.new(), * removes ldns_pkt.section_count() because the underlying C function is marked static and cannot be called, * fixed memory leak when calling ldns_pkt.get_section_clone(). 0002) Adds new file contrib/python/examples/test_pkt.py. This script is created mainly for testing purposes. I've tested the changes in Python 2.7 and 3.2. The changes are related to broken code only so there should be no compatibility issues. Best regards, K. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PyLDNS-Various-fixes-in-ldns_pkt-class.patch Type: text/x-patch Size: 70176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-PyLDNS-Added-test_pkt.py.patch Type: text/x-patch Size: 54069 bytes Desc: not available URL: From willem at nlnetlabs.nl Tue Aug 27 09:33:34 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 27 Aug 2013 11:33:34 +0200 Subject: [ldns-users] pyldns patches In-Reply-To: <521B6249.5070406@nic.cz> References: <521B6249.5070406@nic.cz> Message-ID: <521C726E.6010205@nlnetlabs.nl> Thanks Karel, Patches applied, committed *and* pushed :) -- Willem Op 26-08-13 16:12, Karel Slany schreef: > Hello Wouter and Willem, > > I've created another set of patches. This time it fixes issues which > I've encountered in ldns_pkt class. There are two files in the attachment: > > 0001) * Adds necessary cloning of member structures in several wrapper > methods in order to prevent double free issues, > * adds new method ldns_pkt.new(), > * removes ldns_pkt.section_count() because the underlying C > function is marked static and cannot be called, > * fixed memory leak when calling ldns_pkt.get_section_clone(). > 0002) Adds new file contrib/python/examples/test_pkt.py. This script is > created mainly for testing purposes. > > I've tested the changes in Python 2.7 and 3.2. The changes are related > to broken code only so there should be no compatibility issues. > > Best regards, > K. > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From karel.slany at nic.cz Tue Aug 27 09:53:34 2013 From: karel.slany at nic.cz (Karel Slany) Date: Tue, 27 Aug 2013 11:53:34 +0200 Subject: [ldns-users] pyldns patches In-Reply-To: <521C726E.6010205@nlnetlabs.nl> References: <521B6249.5070406@nic.cz> <521C726E.6010205@nlnetlabs.nl> Message-ID: <521C771E.4010607@nic.cz> It seems that you have forgotten to add contrib/python/examples/test_pkt.py in the last commit. K. Am 27.08.2013 11:33, schrieb Willem Toorop: > Thanks Karel, Patches applied, committed *and* pushed :) > -- Willem > > Op 26-08-13 16:12, Karel Slany schreef: >> Hello Wouter and Willem, >> >> I've created another set of patches. This time it fixes issues which >> I've encountered in ldns_pkt class. There are two files in the attachment: >> >> 0001) * Adds necessary cloning of member structures in several wrapper >> methods in order to prevent double free issues, >> * adds new method ldns_pkt.new(), >> * removes ldns_pkt.section_count() because the underlying C >> function is marked static and cannot be called, >> * fixed memory leak when calling ldns_pkt.get_section_clone(). >> 0002) Adds new file contrib/python/examples/test_pkt.py. This script is >> created mainly for testing purposes. >> >> I've tested the changes in Python 2.7 and 3.2. The changes are related >> to broken code only so there should be no compatibility issues. >> >> Best regards, >> K. >> >> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From willem at nlnetlabs.nl Tue Aug 27 10:42:37 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 27 Aug 2013 12:42:37 +0200 Subject: [ldns-users] pyldns patches In-Reply-To: <521C771E.4010607@nic.cz> References: <521B6249.5070406@nic.cz> <521C726E.6010205@nlnetlabs.nl> <521C771E.4010607@nic.cz> Message-ID: <521C829D.1000302@nlnetlabs.nl> I am afraid I did :( Now *added*, committed and pushed. Sorry about that. Still getting used to git... Op 27-08-13 11:53, Karel Slany schreef: > It seems that you have forgotten to add > contrib/python/examples/test_pkt.py in the last commit. > > K. > > Am 27.08.2013 11:33, schrieb Willem Toorop: >> Thanks Karel, Patches applied, committed *and* pushed :) >> -- Willem >> >> Op 26-08-13 16:12, Karel Slany schreef: >>> Hello Wouter and Willem, >>> >>> I've created another set of patches. This time it fixes issues which >>> I've encountered in ldns_pkt class. There are two files in the attachment: >>> >>> 0001) * Adds necessary cloning of member structures in several wrapper >>> methods in order to prevent double free issues, >>> * adds new method ldns_pkt.new(), >>> * removes ldns_pkt.section_count() because the underlying C >>> function is marked static and cannot be called, >>> * fixed memory leak when calling ldns_pkt.get_section_clone(). >>> 0002) Adds new file contrib/python/examples/test_pkt.py. This script is >>> created mainly for testing purposes. >>> >>> I've tested the changes in Python 2.7 and 3.2. The changes are related >>> to broken code only so there should be no compatibility issues. >>> >>> Best regards, >>> K. >>> >>> >>> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From iwbl5o at nottheoilrig.com Wed Aug 28 18:34:37 2013 From: iwbl5o at nottheoilrig.com (Jack Bates) Date: Wed, 28 Aug 2013 11:34:37 -0700 Subject: [ldns-users] Python rdf.data() In-Reply-To: <52160495.7010009@nic.cz> References: <521549A6.7030809@nottheoilrig.com> <5215D255.4090009@nlnetlabs.nl> <52160495.7010009@nic.cz> Message-ID: <521E42BD.1020809@nottheoilrig.com> Thank you Karel, I want to access certificate association data from a TLSA RR. From C I would use ldns_rdf_data() and ldns_rdf_size(), is that right? From Python, how do you use the return value from rdf.data()? The RDF is type HEX, so str(rdf) returns hex digits. I can convert them back to bytes, but rdf.data() and rdf.size() seemed like the more direct way to get the bytes? On 22/08/13 05:31 AM, Karel Slany wrote: > Greetings, > > Python's ldns_rdf.data() creates a thin wrapper around the ldns C > function ldns_rdf_data(). Function ldns_rdf_data() returns a pointer to > an internal data field of the manipulated rdf. > > Actually, I don't know the actual reason why you are trying to access > this low level structures. Manipulating them from Python can be tricky > as you can easily end up with corrupted memory. > > In order to meet your desire I can add a new method ldns_rdf.data_str() > which would return a Python string containing copy of the rdf data > field. However, in Python3 this would be error-prone, because Python3 > uses unicode strings. At the moment I cannot guess, whether the approach > would be reliabe in Python3. > > Please give more information about the reason why you want to use > ldns_rdf.data(). Perhaps we could think of a more convenient solution. > > K. > > Am 22.08.2013 10:56, schrieb Willem Toorop: >> Hi Jack, >> >> I suspect raw access is not supported by pyldns. >> Karel, could shed some light on this? >> >> -- Willem >> >> Op 22-08-13 01:13, Jack Bates schreef: >>> I am working with the Python wrapper for ldns. >>> >>> rdf.data() returns something like >>> >>> >>> and rdf.size() returns the number of bytes. How do I read the bytes? >>> >>> Thanks! >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>