[ldns-users] pyLDNS Problems

Bedrich Kosata bedrich.kosata at nic.cz
Fri Aug 26 06:25:36 UTC 2011


Dear Chris,

regarding the segfaults you mentioned, the whole process of extracting 
RRs from a packet, RDFs from a RR, etc. was reworked, which should have 
fixed related segfaults.
If you find any such problems still occurring, even though less often, 
it would be great if you could pinpoint the problem to some specific 
part of code, because it could mean some bug in the current solution (or 
some unrelated, not yet discovered issue).

Best regards

Beda

On 08/25/2011 10:32 PM, Paul Wouters wrote:
>
> Forwarding on behalve of Chris,
>
> ---------- Forwarded message ----------
> From: Christopher Olah <christopherolah.co at gmail.com>
> To: ldns-users at open.nlnetlabs.nl
> Date: Thu, 25 Aug 2011 15:15:52 -0400
> Subject: pyLDNS Problems
>
> Hey all,
>
> Over the last few months I've made extensive use of pyLDNS and even
> written a wrapper over it, ldnsx
> (http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=summary).
> I've ran a number of bugs, many of which you seem to have resolved in
> the latest release. Still, there remain some that are deeply
> problematic for me:
>
> (1) ldns_resolver stops responding
>
> Creating reproducible errors here is tricky, because things are so
> dependent on the state of things outside my control. However, the
> following code has been demonstrating it quite reliability on centos6
> with pyLDNS 1.3.40
>
> import ldns
>
> ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf")
> #Drop nameservers
> while self._ldns_resolver.pop_nameserver():
>     pass
> #Set nameserver to xelerance's to aid repropducability
> address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65")
> ldns_resolver.push_nameserver(address)
> #Make queries. The first will work OK, but the next two will break.
> print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )
> print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )
> print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )
>
> It just returns Nones. Contrast this with dig ANY xelerance.com
> @76.10.157.65
>
> Some observations: This bug seems to be associated with truncated
> packets. Using
>
> ldns_resolver.set_usevc(True)
>
> will make the above code run smoothly. On the other hand, it doesn't
> seem to be the only thing going on here. I've had the exact same code
> run fine on the past (though there was a server change since this
> particular example started failing consistently) and I've had other
> examples that weren't truncated fail in the past.
>
> Another observation: If you run with ldns_resolver._debug = True, it
> will print:
>
> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
> ;; flags: rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;; xelerance.com.       IN      ANY
>
> ;; ANSWER SECTION:
>
> ;; AUTHORITY SECTION:
>
> ;; ADDITIONAL SECTION:
>
> ;; Query time: 0 msec
> ;; WHEN: Thu Aug 25 14:25:13 2011
> ;; MSG SIZE  rcvd: 0
>
> My experience with this bug is that it will stop occurring seemingly
> at random...
>
> (2) Random segfaults
>
> I don't have any reproducible instances of this bug in the latest
> version of pyLDNS, though calls to ldnsx.get_rrs will consistently
> cause it to segfault in older versions. Translating it into ldns code
> would be somewhat tedious and long, so I'll leave it out.
>
> This isn't an overly big issue, since it has become quite infrequent
> in the latest release.
>
> Christopher Olah
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users


-- 
Bedrich Kosata
CZ.NIC Labs <http://labs.nic.cz>



More information about the ldns-users mailing list