From karel.slany at nic.cz Tue Jul 10 15:34:12 2012 From: karel.slany at nic.cz (Karel Slany) Date: Tue, 10 Jul 2012 17:34:12 +0200 Subject: [ldns-users] fixing pyldns signzone example Message-ID: <4FFC4B74.4000008@nic.cz> Hello, I'm working with pyldns again and I've discovered several issues all addressing the ldns-signzone.py example. Description of the issues: The behaviour of the ldns_rr_new_frm_fp_l_() wrapper function has been modified. The modification caused Python code errors in the ldns_struct_rr.new_frm_fp* functions. To preserve the functionality of ldns_struct_rr.new_frm_fp (according to it's docstring) I've introduced a new wrapper function ldns_rr_new_frm_fp_(). The ldns_dnssec_zone.add_rr() function caused memory corruption issues -- double frees or accessing of recently freed memory. The Python engine freed the inserted RR after the reference counter had reached zero. Because the ldns_dnssec_zone_add_rr does not create a copy of the given RR so there is a chance of segmentation faults when using this function directly from Python code. Therefore I've added the ldns_dnssec_zone_add_rr_() wrapper function which creates a copy of the inserted RR into the zone. I've also fixed the pyldns Makefile testenv target entry which used wrong relative path to _ldns.so. The patch also introduces a new Python3 example file to the SVN repository so please don't forget to set the script executable and to 'svn add' it. chmod +x trunk/contrib/python/examples/python3/ldns-signzone.py svn add trunk/contrib/python/examples/python3/ldns-signzone.py I've tested the patch using Python 2.7 and 3.2. As far as I'm concerned, the patch does not break any current code. Best regards, K. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: signzone_example_fix.diff URL: From msheldon at godaddy.com Wed Jul 11 17:12:00 2012 From: msheldon at godaddy.com (Michael Sheldon) Date: Wed, 11 Jul 2012 10:12:00 -0700 Subject: [ldns-users] =?utf-8?q?Memory_leak_in_keys=2Ec=2C_ldns=5Fkey=5Fne?= =?utf-8?q?w=5Ffrm=5Falgorithm?= Message-ID: <20120711101200.205a61dff9fc1684c258b274662bb912.ab31fcea1b.wbe@email00.secureserver.net> There are two memory leaks in keys.c, ldns_key_new_frm_algorithm The issue in the following is that ldns_key_set_rsa_key uses EVP_PKEY_set1_RSA(), which *copies* the RSA data, thus the original data must be freed by the calling application. 00837 case LDNS_SIGN_RSAMD5: 00838 case LDNS_SIGN_RSASHA1: 00839 case LDNS_SIGN_RSASHA1_NSEC3: 00840 case LDNS_SIGN_RSASHA256: 00841 case LDNS_SIGN_RSASHA512: 00842 #ifdef HAVE_SSL 00843 r = RSA_generate_key((int)size, RSA_F4, NULL, NULL); 00844 if(!r) { 00845 ldns_key_free(k); 00846 return NULL; 00847 } 00848 if (RSA_check_key(r) != 1) { 00849 ldns_key_free(k); 00850 return NULL; 00851 } 00852 ldns_key_set_rsa_key(k, r); 00853 #endif /* HAVE_SSL */ 00854 break; The solution is to use RSA_free(r) after line 852. The same issue applies in the following code. ldns_key_set_dsa_key uses EVP_PKEY_set1_DSA(), which *copies* the DSA data, thus the original data must be freed by the calling application. 00855 case LDNS_SIGN_DSA: 00856 case LDNS_SIGN_DSA_NSEC3: 00857 #ifdef HAVE_SSL 00858 d = DSA_generate_parameters((int)size, NULL, 0, NULL, NULL, NULL, NULL); 00859 if (!d) { 00860 ldns_key_free(k); 00861 return NULL; 00862 } 00863 if (DSA_generate_key(d) != 1) { 00864 ldns_key_free(k); 00865 return NULL; 00866 } 00867 ldns_key_set_dsa_key(k, d); 00868 #endif /* HAVE_SSL */ 00869 break; The solution is to use DSA_free(d) after line 867. An alternative solution is to use EVP_PKEY_assign_RSA and EVP_PKEY_assign_DSA in place of EVP_PKEY_set1_RSA and EVP_PKEY_set1_DSA. The problem here is that it changes the existing behaviour of ldns_key_set_rsa_key and ldns_key_set_dsa_key, which developers may be calling. Michael Sheldon Dev-DNS Services GoDaddy.com From willem at nlnetlabs.nl Fri Jul 13 08:16:23 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 13 Jul 2012 10:16:23 +0200 Subject: [ldns-users] fixing pyldns signzone example In-Reply-To: <4FFC4B74.4000008@nic.cz> References: <4FFC4B74.4000008@nic.cz> Message-ID: <4FFFD957.6060900@nlnetlabs.nl> Hi Karel, Thanks for the fixes and new example script. Applied and added to trunk. Best regards, -- Willem Op 10-07-12 17:34, Karel Slany schreef: > Hello, > > I'm working with pyldns again and I've discovered several issues all > addressing the ldns-signzone.py example. > > Description of the issues: > > The behaviour of the ldns_rr_new_frm_fp_l_() wrapper function has been > modified. The modification caused Python code errors in the > ldns_struct_rr.new_frm_fp* functions. To preserve the functionality of > ldns_struct_rr.new_frm_fp (according to it's docstring) I've introduced > a new wrapper function ldns_rr_new_frm_fp_(). > > The ldns_dnssec_zone.add_rr() function caused memory corruption issues > -- double frees or accessing of recently freed memory. The Python engine > freed the inserted RR after the reference counter had reached zero. > Because the ldns_dnssec_zone_add_rr does not create a copy of the given > RR so there is a chance of segmentation faults when using this function > directly from Python code. Therefore I've added the > ldns_dnssec_zone_add_rr_() wrapper function which creates a copy of the > inserted RR into the zone. > > I've also fixed the pyldns Makefile testenv target entry which used > wrong relative path to _ldns.so. > > The patch also introduces a new Python3 example file to the SVN > repository so please don't forget to set the script executable and to > 'svn add' it. > > chmod +x trunk/contrib/python/examples/python3/ldns-signzone.py > svn add trunk/contrib/python/examples/python3/ldns-signzone.py > > I've tested the patch using Python 2.7 and 3.2. As far as I'm concerned, > the patch does not break any current code. > > Best regards, > K. > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From willem at nlnetlabs.nl Fri Jul 13 08:39:30 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 13 Jul 2012 10:39:30 +0200 Subject: [ldns-users] Memory leak in keys.c, ldns_key_new_frm_algorithm In-Reply-To: <20120711101200.205a61dff9fc1684c258b274662bb912.ab31fcea1b.wbe@email00.secureserver.net> References: <20120711101200.205a61dff9fc1684c258b274662bb912.ab31fcea1b.wbe@email00.secureserver.net> Message-ID: <4FFFDEC2.606@nlnetlabs.nl> Hi Michael, Indeed. I have added two new ldns functions ldns_key_assign_dsa_key and ldns_key_assign_rsa_key and use those from ldns_key_new_frm_algorithm, to maintain the API but prevent unnecessary allocations/frees. Thanks for spotting this! -- Willem Op 11-07-12 19:12, Michael Sheldon schreef: > There are two memory leaks in keys.c, ldns_key_new_frm_algorithm > > The issue in the following is that ldns_key_set_rsa_key uses > EVP_PKEY_set1_RSA(), which *copies* the RSA data, thus the original data > must be freed by the calling application. > > 00837 case LDNS_SIGN_RSAMD5: > 00838 case LDNS_SIGN_RSASHA1: > 00839 case LDNS_SIGN_RSASHA1_NSEC3: > 00840 case LDNS_SIGN_RSASHA256: > 00841 case LDNS_SIGN_RSASHA512: > 00842 #ifdef HAVE_SSL > 00843 r = RSA_generate_key((int)size, RSA_F4, > NULL, NULL); > 00844 if(!r) { > 00845 ldns_key_free(k); > 00846 return NULL; > 00847 } > 00848 if (RSA_check_key(r) != 1) { > 00849 ldns_key_free(k); > 00850 return NULL; > 00851 } > 00852 ldns_key_set_rsa_key(k, r); > 00853 #endif /* HAVE_SSL */ > 00854 break; > > The solution is to use RSA_free(r) after line 852. > > The same issue applies in the following code. ldns_key_set_dsa_key uses > EVP_PKEY_set1_DSA(), which *copies* the DSA data, thus the original data > must be freed by the calling application. > > 00855 case LDNS_SIGN_DSA: > 00856 case LDNS_SIGN_DSA_NSEC3: > 00857 #ifdef HAVE_SSL > 00858 d = DSA_generate_parameters((int)size, > NULL, 0, NULL, NULL, NULL, NULL); > 00859 if (!d) { > 00860 ldns_key_free(k); > 00861 return NULL; > 00862 } > 00863 if (DSA_generate_key(d) != 1) { > 00864 ldns_key_free(k); > 00865 return NULL; > 00866 } > 00867 ldns_key_set_dsa_key(k, d); > 00868 #endif /* HAVE_SSL */ > 00869 break; > > The solution is to use DSA_free(d) after line 867. > > An alternative solution is to use EVP_PKEY_assign_RSA and > EVP_PKEY_assign_DSA in place of EVP_PKEY_set1_RSA and EVP_PKEY_set1_DSA. > The problem here is that it changes the existing behaviour of > ldns_key_set_rsa_key and ldns_key_set_dsa_key, which developers may be > calling. > > Michael Sheldon > Dev-DNS Services > GoDaddy.com > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From msheldon at godaddy.com Fri Jul 13 22:22:01 2012 From: msheldon at godaddy.com (Michael Sheldon) Date: Fri, 13 Jul 2012 15:22:01 -0700 Subject: [ldns-users] =?utf-8?q?Bug=2C_or_known_limitation=3F=3F=3F?= Message-ID: <20120713152201.205a61dff9fc1684c258b274662bb912.7eb113bcb5.wbe@email00.secureserver.net> When using ldns_zone_sign_nsec3(), if I pass it a keyring having multiple KSK and/or ZSK, it only signs the zone with one of each. Using multiple keys is pretty normal, especially during key rollovers, so it's a necessary thing. So is this a bug? Michael Sheldon Dev-DNS Services GoDaddy.com From msheldon at godaddy.com Fri Jul 13 22:57:47 2012 From: msheldon at godaddy.com (Michael Sheldon) Date: Fri, 13 Jul 2012 15:57:47 -0700 Subject: [ldns-users] =?utf-8?b?QnVnLF9vcl9rbm93bl9saW1pdGF0aW9uPz8/?= Message-ID: <20120713155747.205a61dff9fc1684c258b274662bb912.bc3ef80909.wbe@email00.secureserver.net> Tunnelled deep enough to find it. Bug #458 submitted Error is in ldns_dnssec_zone_create_rrsigs_flg(). All the signatures are being generated, but only the first RRSIG for an rrset is being added to the new_rrs list structure for ldns_dnssec_zone_sign_nsec3(), which is called by ldns_zone_sign_nsec3(). Michael Sheldon Dev-DNS Services GoDaddy.com > -------- Original Message -------- > Subject: [ldns-users] Bug,_or_known_limitation??? > From: "Michael Sheldon" > Date: Fri, July 13, 2012 3:22 pm > To: "ldns-users at open.nlnetlabs.nl" > > > When using ldns_zone_sign_nsec3(), if I pass it a keyring having > multiple KSK and/or ZSK, it only signs the zone with one of each. Using > multiple keys is pretty normal, especially during key rollovers, so it's > a necessary thing. > > So is this a bug? > > Michael Sheldon > Dev-DNS Services > GoDaddy.com > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From vieuxtech at gmail.com Mon Jul 16 23:15:14 2012 From: vieuxtech at gmail.com (Sam Roberts) Date: Mon, 16 Jul 2012 16:15:14 -0700 Subject: [ldns-users] should I be using ldns or libunbound? Message-ID: I need a lua binding for async dns. I want to use an event loop external to the library, so that I can integrate dns support into larger lua applications. I started using udns, but its support seems lacking, and the author himself suggested maybe ldns should be used instead... But ldns doesn't seem to have an examples or docs of doing anything asynchronously, is this the wrong library for me? Should even be looking at ldns? Thanks, Sam From paul at nohats.ca Mon Jul 16 23:55:40 2012 From: paul at nohats.ca (Paul Wouters) Date: Mon, 16 Jul 2012 19:55:40 -0400 (EDT) Subject: [ldns-users] should I be using ldns or libunbound? In-Reply-To: References: Message-ID: On Mon, 16 Jul 2012, Sam Roberts wrote: > I need a lua binding for async dns. I want to use an event loop > external to the library, so that I can integrate dns support into > larger lua applications. > > I started using udns, but its support seems lacking, and the author > himself suggested maybe ldns should be used instead... But ldns > doesn't seem to have an examples or docs of doing anything > asynchronously, is this the wrong library for me? Should even be > looking at ldns? I think you want to look at unbound: http://www.unbound.net/documentation/libunbound-tutorial-4.html unbound uses ldns itself. Paul From willem at nlnetlabs.nl Tue Jul 17 10:25:03 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 17 Jul 2012 12:25:03 +0200 Subject: [ldns-users] Bug,_or_known_limitation??? In-Reply-To: <20120713155747.205a61dff9fc1684c258b274662bb912.bc3ef80909.wbe@email00.secureserver.net> References: <20120713155747.205a61dff9fc1684c258b274662bb912.bc3ef80909.wbe@email00.secureserver.net> Message-ID: <50053D7F.7030503@nlnetlabs.nl> Hi Michael, This was definitely a bug. I have it resolved in trunk. Thanks again for finding and reporting! -- Willem Op 14-07-12 00:57, Michael Sheldon schreef: > Tunnelled deep enough to find it. Bug #458 submitted > > Error is in ldns_dnssec_zone_create_rrsigs_flg(). All the signatures > are being generated, but only the first RRSIG for an rrset is being > added to the new_rrs list structure for ldns_dnssec_zone_sign_nsec3(), > which is called by ldns_zone_sign_nsec3(). > > > Michael Sheldon > Dev-DNS Services > GoDaddy.com > >> -------- Original Message -------- >> Subject: [ldns-users] Bug,_or_known_limitation??? >> From: "Michael Sheldon" >> Date: Fri, July 13, 2012 3:22 pm >> To: "ldns-users at open.nlnetlabs.nl" >> >> >> When using ldns_zone_sign_nsec3(), if I pass it a keyring having >> multiple KSK and/or ZSK, it only signs the zone with one of each. Using >> multiple keys is pretty normal, especially during key rollovers, so it's >> a necessary thing. >> >> So is this a bug? >> >> Michael Sheldon >> Dev-DNS Services >> GoDaddy.com >> >> >> _______________________________________________ >> 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 Jul 17 10:27:53 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 17 Jul 2012 12:27:53 +0200 Subject: [ldns-users] should I be using ldns or libunbound? In-Reply-To: References: Message-ID: <50053E29.8090007@nlnetlabs.nl> Hi Sam, Indeed, you should use libunbound when you need a resolver library. Cheers, -- Willem Op 17-07-12 01:55, Paul Wouters schreef: > On Mon, 16 Jul 2012, Sam Roberts wrote: > >> I need a lua binding for async dns. I want to use an event loop >> external to the library, so that I can integrate dns support into >> larger lua applications. >> >> I started using udns, but its support seems lacking, and the author >> himself suggested maybe ldns should be used instead... But ldns >> doesn't seem to have an examples or docs of doing anything >> asynchronously, is this the wrong library for me? Should even be >> looking at ldns? > > I think you want to look at unbound: > > http://www.unbound.net/documentation/libunbound-tutorial-4.html > > unbound uses ldns itself. > > Paul > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From vieuxtech at gmail.com Tue Jul 17 17:49:25 2012 From: vieuxtech at gmail.com (Sam Roberts) Date: Tue, 17 Jul 2012 10:49:25 -0700 Subject: [ldns-users] should I be using ldns or libunbound? In-Reply-To: <50053E29.8090007@nlnetlabs.nl> References: <50053E29.8090007@nlnetlabs.nl> Message-ID: On Tue, Jul 17, 2012 at 3:27 AM, Willem Toorop wrote: > Indeed, you should use libunbound when you need a resolver library. Thanks, you all. Btw, I find it interesting that ldns has a lua binding... Maybe libunbound will, too, if I get a bit more time to work on it. Sam From karel.slany at nic.cz Wed Jul 18 17:23:26 2012 From: karel.slany at nic.cz (Karel Slany) Date: Wed, 18 Jul 2012 19:23:26 +0200 Subject: [ldns-users] undefined symbols in _ldns.so Message-ID: <5006F10E.1020808@nic.cz> Hello guys, today I discovered a nasty bug in SVN code (at revision 3706) which is prohibiting a correct import of lnds in python code. See the error message: >>> import ldns Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/site-packages/ldns.py", line 26, in _ldns = swig_import_helper() File "/usr/lib64/python2.7/site-packages/ldns.py", line 22, in swig_import_helper _mod = imp.load_module('_ldns', fp, pathname, description) ImportError: /usr/lib64/python2.7/site-packages/_ldns.so: undefined symbol: qsort_rr_compare_nsec3 The module library _ldns.so cannot resolve symbols from libldns. The bug was introduced in commit 3705 and the attached patch fixes it. Cheers, K. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldns_missing_symbols.diff URL: From edmonds at debian.org Wed Jul 18 19:58:21 2012 From: edmonds at debian.org (Robert Edmonds) Date: Wed, 18 Jul 2012 15:58:21 -0400 Subject: [ldns-users] undefined symbols in _ldns.so In-Reply-To: <5006F10E.1020808@nic.cz> References: <5006F10E.1020808@nic.cz> Message-ID: <20120718195821.GA28641@mycre.ws> Karel Slany wrote: > The bug was introduced in commit 3705 and the attached patch fixes it. no, "-export-symbols" is correct. there is no "--export-symbols" option to libtool. https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=459 perhaps "qsort_rr_compare_nsec3" (and probably "qsort_rr_compare" and "qsort_schwartz_rr_compare") should be added to ldns_symbols.def, as these symbols were exported previously. -- Robert Edmonds edmonds at debian.org From Willem at NLnetLabs.nl Wed Jul 18 21:40:26 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 18 Jul 2012 23:40:26 +0200 Subject: [ldns-users] undefined symbols in _ldns.so In-Reply-To: <20120718195821.GA28641@mycre.ws> References: <5006F10E.1020808@nic.cz> <20120718195821.GA28641@mycre.ws> Message-ID: <50072D4A.5020104@NLnetLabs.nl> Op 18-07-12 21:58, Robert Edmonds schreef: > Karel Slany wrote: >> The bug was introduced in commit 3705 and the attached patch fixes it. > perhaps "qsort_rr_compare_nsec3" (and probably "qsort_rr_compare" and > "qsort_schwartz_rr_compare") should be added to ldns_symbols.def, as > these symbols were exported previously. Well... qsort_rr_compare and qsort_schwartz_rr_compare are not in the header files and thus not in the api. So I've only added qsort_rr_compare_nsec3. And also b32_ntop, b32_ntop_extended_hex, b32_pton and b32_pton_extended_hex which were also exported before and in util.h. Willem From edmonds at debian.org Wed Jul 18 21:47:17 2012 From: edmonds at debian.org (Robert Edmonds) Date: Wed, 18 Jul 2012 17:47:17 -0400 Subject: [ldns-users] undefined symbols in _ldns.so In-Reply-To: <50072D4A.5020104@NLnetLabs.nl> References: <5006F10E.1020808@nic.cz> <20120718195821.GA28641@mycre.ws> <50072D4A.5020104@NLnetLabs.nl> Message-ID: <20120718214717.GA28175@mycre.ws> Willem Toorop wrote: > Op 18-07-12 21:58, Robert Edmonds schreef: > > Karel Slany wrote: > >> The bug was introduced in commit 3705 and the attached patch fixes it. > > perhaps "qsort_rr_compare_nsec3" (and probably "qsort_rr_compare" and > > "qsort_schwartz_rr_compare") should be added to ldns_symbols.def, as > > these symbols were exported previously. > > Well... qsort_rr_compare and qsort_schwartz_rr_compare are not in the > header files and thus not in the api. So I've only added > qsort_rr_compare_nsec3. And also b32_ntop, b32_ntop_extended_hex, > b32_pton and b32_pton_extended_hex which were also exported before and > in util.h. true, i was just looking at the symbols in the .so file and not the headers. i see the following symbols exported by the 1.6.13 ldns library in debian that don't have the ldns_ prefix: 00000000000430c0 T b32_ntop 00000000000430e0 T b32_ntop_extended_hex 0000000000042ae0 T b32_pton 0000000000042b00 T b32_pton_extended_hex 0000000000040820 T mktime_from_utc 0000000000037da0 T qsort_rr_compare 000000000001bc50 T qsort_rr_compare_nsec3 0000000000038040 T qsort_schwartz_rr_compare 00000000000430f0 T strlcpy 00000000000404a0 T xprintf_hex 0000000000040390 T xprintf_rdf 0000000000040430 T xprintf_rr -- Robert Edmonds edmonds at debian.org From Willem at NLnetLabs.nl Wed Jul 18 21:57:40 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 18 Jul 2012 23:57:40 +0200 Subject: [ldns-users] undefined symbols in _ldns.so In-Reply-To: <20120718214717.GA28175@mycre.ws> References: <5006F10E.1020808@nic.cz> <20120718195821.GA28641@mycre.ws> <50072D4A.5020104@NLnetLabs.nl> <20120718214717.GA28175@mycre.ws> Message-ID: <50073154.6010601@NLnetLabs.nl> Yes, those should get the ldns_ prefix at some point, but until a major version number update (1.7) we have to leave them in I suppose. Thank you Karel and Robert for pointing it out. It would have been nasty if it would have shipped like that... Op 18-07-12 23:47, Robert Edmonds schreef: > Willem Toorop wrote: >> Op 18-07-12 21:58, Robert Edmonds schreef: >>> Karel Slany wrote: >>>> The bug was introduced in commit 3705 and the attached patch fixes it. >>> perhaps "qsort_rr_compare_nsec3" (and probably "qsort_rr_compare" and >>> "qsort_schwartz_rr_compare") should be added to ldns_symbols.def, as >>> these symbols were exported previously. >> >> Well... qsort_rr_compare and qsort_schwartz_rr_compare are not in the >> header files and thus not in the api. So I've only added >> qsort_rr_compare_nsec3. And also b32_ntop, b32_ntop_extended_hex, >> b32_pton and b32_pton_extended_hex which were also exported before and >> in util.h. > > true, i was just looking at the symbols in the .so file and not the > headers. i see the following symbols exported by the 1.6.13 ldns > library in debian that don't have the ldns_ prefix: > > 00000000000430c0 T b32_ntop > 00000000000430e0 T b32_ntop_extended_hex > 0000000000042ae0 T b32_pton > 0000000000042b00 T b32_pton_extended_hex > > 0000000000040820 T mktime_from_utc > > 0000000000037da0 T qsort_rr_compare > 000000000001bc50 T qsort_rr_compare_nsec3 > 0000000000038040 T qsort_schwartz_rr_compare > > 00000000000430f0 T strlcpy > > 00000000000404a0 T xprintf_hex > 0000000000040390 T xprintf_rdf > 0000000000040430 T xprintf_rr > From karel.slany at nic.cz Fri Jul 20 12:43:59 2012 From: karel.slany at nic.cz (Karel Slany) Date: Fri, 20 Jul 2012 14:43:59 +0200 Subject: [ldns-users] ldns_buffer2str asserting after ldns_buffer_copy Message-ID: <5009528F.7080200@nic.cz> Hello again, I'm writing some scripts for automated checking of pyLDNS basic functionality. I have encountered strange behaviour of the ldns_buffer_copy and ldns_buffer2str function. ldns_buffer: ./buffer.c:82: ldns_buffer_reserve: Assertion `!buffer->_fixed' failed. I am not sure whether this is a bug or I am missing something. But I haven't found any clues in the documentation telling me why this shouldn't work. I've rewritten the code to C, in order to make it more understandable: #include #include int main(void) { ldns_buffer *b1, *b2; char *str; b1 = ldns_buffer_new(1024); b2 = ldns_buffer_new(10); ldns_buffer_printf(b1, "%s", "abc"); ldns_buffer_printf(b2, "%s", "def"); str = ldns_buffer2str(b1); fprintf(stdout, "b1: %s\n", str); LDNS_FREE(str); str = ldns_buffer2str(b2); fprintf(stdout, "b2: %s\n", str); LDNS_FREE(str); ldns_buffer_copy(b1, b2); str = ldns_buffer2str(b1); /* Asserts here. */ fprintf(stdout, "b1: %s\n", str); LDNS_FREE(str); str = ldns_buffer2str(b2); fprintf(stdout, "b2: %s\n", str); LDNS_FREE(str); ldns_buffer_free(b1); ldns_buffer_free(b2); } The comment shows the position, where the code is asserting. I've tested ldns 1.6.13 and also the latest SVN (revision 3707), both behave the same. K. From marius.rieder at durchmesser.ch Thu Jul 26 07:58:57 2012 From: marius.rieder at durchmesser.ch (Marius Rieder) Date: Thu, 26 Jul 2012 09:58:57 +0200 Subject: [ldns-users] ldns_resolver_pop_nameserver and ldns_resolver_deep_free Message-ID: <5010F8C1.7030104@durchmesser.ch> Hi, If i remove all nameserver with ldns_resolver_pop_nameserver and do a ldns_resolver_deep_free later. Ldns double frees the r->_nameservers and r->_rtt. ldns_resolver_pop_nameserver reallocs [1]boath with size 0, which is a equivalent to free. Which is perfect fine, but do not update the pointer in the ldns_resolver. [1]http://www.nlnetlabs.nl/projects/ldns/doc/resolver_8c_source.html#l00256 As realloc could return NULL in case of a failed realloc aswell, it may be nessesary to check the ns_count eigther in ldns_resolver_pop_nameserver or ldns_resolver_deep_free. - Marius -- ~o__O Marius Rieder O__o~ |vV| http://www.durchmesser.ch/ |vV| /] | | [\ ---/|--|\--------[ Dance first. Think later. ]--------/|--|\--- From karel.slany at nic.cz Tue Jul 31 12:46:38 2012 From: karel.slany at nic.cz (Karel Slany) Date: Tue, 31 Jul 2012 14:46:38 +0200 Subject: [ldns-users] pyLDNS fixes in ldns_buffer, ldns_rdf, ldns_dname and others Message-ID: <5017D3AE.50707@nic.cz> Hello, I've written three scripts testing the functionality of ldns_buffer, ldns_rdf and ldns_dname Python classes. By running the scripts I've encountered several problems which have been fixed in the attached patch. The patch also contains the mentioned testing scripts, which need to be added into the repository in order to prevent breaking the functionality by code changes in future. So please don't forget to: svn add trunk/contrib/python/examples/test_*.py chmod +x trunk/contrib/python/examples/test_*.py Description of the fixed issues follows. Python 3 related: * Fixed automatic conversion from string to ldns_rdf and ldns_dname. Caused memory corruption when using Python 3. The #ifdef SWIG_Python_str_AsChar does not actually work as SWIG_Python_str_AsChar is a function (at least in SWIG 2.0.4), so it has been replaced. Also in Python 3 the conversion would have caused memory leaks if it was working. * In Python 3 the wrapper now raises TypeError instead of ValueError when receiving a non FILE * argument when it should receive a FILE * argument. In Python 2 it raises TypeError by default, so it was changed to comply with Python 2. Python serious issues: * Fixed wrong handling of _ldns_rr_list_free() and _ldns_rr_list_deep_free() when compiling with LDNS_DEBUG directive. * Fixed malfunctioning ldns.ldns_rdf_new_frm_fp_l(). * Fixed malfunctioning ldns_drf.absolute() and ldns_dname.absolute() * Marked several functions related to ldns_rdf and ldns_buffer as returning new objects. It could lead to memory leaks, when not marked. (ldns_rdf.address_reverse(), ldns_rdf.cat_clone(), etc.) * And many small fixes preventing code crashes in ldns_buffer, ldns_rdf and ldns_dname. Interface fixes and additions: * Method operating on ldns_dnames and returning dname ldns_rdfs now return ldns_dname instances. (This represents no compatibility issues, as ldns_dname is derived from ldns_rdf.) * Improved documentation of ldns_buffer, ldns_rdf and ldns_dname classes. * Methods ldns_buffer.available() and ldns_buffer.available_at() now return bool types as described in the documentation. * Added scripts for testing of basic functionality of the classes ldns_buffer, ldns_rdf, ldns_dname. * Added deprecation warnings to ldns_rdf methods operating on dname rdfs. The user is encouraged to converts dname ldns_rdfs to ldns_dnames. This saves several lines of sanity checking code in future. * Extended ldns_dname constructor to accept ldns_rdfs containing dnames. I've tested the changes using Python 2.7 and 3.2. The changes maintain backward compatibility. However, in several cases the code will now throw a deprecation warning about changes of the interface in future. Best regards, K. -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_buffer_rdf_dname.patch Type: text/x-patch Size: 156820 bytes Desc: not available URL: