13013 2011-07-21 16:46:00 +0000 assertion error in res_query.c 2012-11-30 20:05:56 +0000 1 1 1 Unclassified glibc network 2.16 All All RESOLVED FIXED P2 normal 2.17 1 aurelien drepper.fsp allan bugzilla davem law mmarek nick.jones pluto timothy.c.pepper toolchain 49962 5855 aurelien 2011-07-21 16:46:14 +0000 Created attachment 5855 Patch to fix the issue Commit 4769ae77fc6c8dacea6476addb015c8797848cdd a regression in the resolver code, which trigger an assert in some conditions: firefox-bin: res_query.c:251: __libc_res_nquery: Assertion `hp != hp2' failed. Aborting. When the first answer is a SERVFAIL, NOTIMP or REFUSED, resplen now got assigned 0, while recvresp1 or recvresp2 is set to 1: /* No data from the first reply. */ resplen = 0; When the second answer arrives, its buffer is allocated at *ansp + resplen, which means in that case *ansp and *ansp2 are equals: *anssizp2 = orig_anssizp - resplen; *ansp2 = *ansp + resplen; Given a second answer has still be provided, hp2 got assigned *answerp2, which is the same than *answer (see above), so hp == hp2. HEADER *hp2 = answerp2 ? (HEADER *) *answerp2 : hp; This is enough to trigger the assertion, that is the checks on the answer buffers doesn't match the checks on the response lengths. One way to fix that is to rewrite this part of the code to do all the checks on the response lenghts. This is what the attached patch does. 52222 6118 fherrera 2011-12-19 03:22:03 +0000 Created attachment 6118 testcase for this bug This testcase triggers the bug using these nameservers: nameserver 87.216.1.65 nameserver 87.216.1.66 52297 drepper.fsp 2011-12-22 00:04:28 +0000 (In reply to comment #1) > Created attachment 6118 [details] > testcase for this bug > > This testcase triggers the bug using these nameservers: > > nameserver 87.216.1.65 > nameserver 87.216.1.66 No, it doesn't. I don't see any assert. 55279 bugzilla 2012-05-17 18:38:26 +0000 I see this too (as does everyone else who uses a non-patched glibc). Hope to see this fixed in 2.15.1 57888 timothy.c.pepper 2012-10-09 21:33:47 +0000 I was lazy and edited an scp command in my shell history to be an ssh command, but forgot to remove the ':', eg: scp file host:/big/long/path ssh host: command /big/long/path That ssh command resulted in the assert noted here, but only on a first try. I'm guessing the query/result is cached and traverses different code subsequently and gives a more expected output like: ssh: Could not resolve hostname host:: Name or service not known 57892 law 2012-10-10 00:31:40 +0000 Tim, what are the contents of your resolv.conf? This issue is highly dependent on the nameservers you use and unfortunately nobody's been able to trigger on public nameservers. I worked with Fernando on analysis in the past, but wasn't able to wrap up before having to switch to another issue. 57915 timothy.c.pepper 2012-10-10 17:28:47 +0000 (In reply to comment #5) > Tim, what are the contents of your resolv.conf? I'm using connman, so my /etc/resolv.conf has simply: # Generated by Connection Manager nameserver 127.0.0.1 connman's then using whatever company internal dns server(s) the local corporate dhcp server told it to use... It's quite easy for me to reproduce, with the exception of not having figured out what's being seemingly cached or where. If there's anything you'd suggest for added instrumentation in glibc, to look for in the corefile, look for in a tcpdump, etc., let me know and I will dig a layer deeper. 57945 law 2012-10-11 18:35:48 +0000 Unfortunately, we're obviously not going to be able to access the DNS server running on your local host. It's certainly relatively easy to reproduce once you've got a nameserver which triggers the problem -- but that's been the incredibly frustrating problem here. Every such name server has been behind a firewall. Given there's a potential patch attached to this BZ, what's really needed is for someone with better knowledge of this code to review that patch. I don't feel qualified to do that review. 58848 davem 2012-11-30 20:05:56 +0000 Fixed in glibc-2.17 5855 2011-07-21 16:46:00 +0000 2011-07-21 16:46:14 +0000 Patch to fix the issue glibc-resolv-assert.diff text/plain 1843 aurelien MjAxMS0wNy0yMSAgQXVyZWxpZW4gSmFybm8gIDxhdXJlbDMyQGRlYmlhbi5vcmc+CgoJKiByZXNv bHYvcmVzX3F1ZXJ5LmMoX19saWJjX3Jlc19ucXVlcnkpOiBBc3NpZ24gaHAgYW5kIGhwMiAKCWRl cGVuZGluZyBuIGFuZCByZXNwbGVuMiB0byBjYXRjaCBjYXNlcyB3aGVyZSBhbnN3ZXIgCgllcXVh bHMgYW5zd2VycDIuCgpkaWZmIC0tZ2l0IGEvcmVzb2x2L3Jlc19xdWVyeS5jIGIvcmVzb2x2L3Jl c19xdWVyeS5jCmluZGV4IDJmN2NmYWEuLjQwNWZhNjggMTAwNjQ0Ci0tLSBhL3Jlc29sdi9yZXNf cXVlcnkuYworKysgYi9yZXNvbHYvcmVzX3F1ZXJ5LmMKQEAgLTEyMiw2ICsxMjIsNyBAQCBfX2xp YmNfcmVzX25xdWVyeShyZXNfc3RhdGUgc3RhdHAsCiAJCSAgaW50ICpyZXNwbGVuMikKIHsKIAlI RUFERVIgKmhwID0gKEhFQURFUiAqKSBhbnN3ZXI7CisJSEVBREVSICpocDI7CiAJaW50IG4sIHVz ZV9tYWxsb2MgPSAwOwogCXVfaW50IG9mbGFncyA9IHN0YXRwLT5fZmxhZ3M7CiAKQEAgLTIzOSwy NiArMjQwLDI1IEBAIF9fbGliY19yZXNfbnF1ZXJ5KHJlc19zdGF0ZSBzdGF0cCwKIAkgIC8qIF9f bGliY19yZXNfbnNlbmQgbWlnaHQgaGF2ZSByZWFsbG9jYXRlZCB0aGUgYnVmZmVyLiAgKi8KIAkg IGhwID0gKEhFQURFUiAqKSAqYW5zd2VycDsKIAotCS8qIFdlIHNpbXBsaWZ5IHRoZSBmb2xsb3dp bmcgdGVzdHMgYnkgYXNzaWduaW5nIEhQIHRvIEhQMi4gIEl0Ci0JICAgaXMgZWFzeSB0byB2ZXJp ZnkgdGhhdCB0aGlzIGlzIHRoZSBzYW1lIGFzIGlnbm9yaW5nIGFsbAotCSAgIHRlc3RzIG9mIEhQ Mi4gICovCi0JSEVBREVSICpocDIgPSBhbnN3ZXJwMiA/IChIRUFERVIgKikgKmFuc3dlcnAyIDog aHA7Ci0KLQlpZiAobiA8IChpbnQpIHNpemVvZiAoSEVBREVSKSAmJiBhbnN3ZXJwMiAhPSBOVUxM Ci0JICAgICYmICpyZXNwbGVuMiA+IChpbnQpIHNpemVvZiAoSEVBREVSKSkKKwkvKiBXZSBzaW1w bGlmeSB0aGUgZm9sbG93aW5nIHRlc3RzIGJ5IGFzc2lnbmluZyBIUCB0byBIUDIgb3IKKwkgICB2 aWNlIHZlcnNhLiAgSXQgaXMgZWFzeSB0byB2ZXJpZnkgdGhhdCB0aGlzIGlzIHRoZSBzYW1lIGFz CisJICAgaWdub3JpbmcgYWxsIHRlc3RzIG9mIEhQIG9yIEhQMi4gICovCisJaWYgKGFuc3dlcnAy ID09IE5VTEwgfHwgKnJlc3BsZW4yIDwgKGludCkgc2l6ZW9mIChIRUFERVIpKQogCSAgewotCSAg ICAvKiBTcGVjaWFsIGNhc2Ugb2YgcGFydGlhbCBhbnN3ZXIuICAqLwotCSAgICBhc3NlcnQgKGhw ICE9IGhwMik7Ci0JICAgIGhwID0gaHAyOworCSAgICBocDIgPSBocDsKIAkgIH0KLQllbHNlIGlm IChhbnN3ZXJwMiAhPSBOVUxMICYmICpyZXNwbGVuMiA8IChpbnQpIHNpemVvZiAoSEVBREVSKQot CQkgJiYgbiA+IChpbnQpIHNpemVvZiAoSEVBREVSKSkKKwllbHNlCiAJICB7Ci0JICAgIC8qIFNw ZWNpYWwgY2FzZSBvZiBwYXJ0aWFsIGFuc3dlci4gICovCi0JICAgIGFzc2VydCAoaHAgIT0gaHAy KTsKLQkgICAgaHAyID0gaHA7CisJICAgIGhwMiA9IChIRUFERVIgKikgKmFuc3dlcnAyOworCSAg ICBpZiAobiA8IChpbnQpIHNpemVvZiAoSEVBREVSKSkKKwkgICAgICB7CisJICAgICAgICBocCA9 IGhwMjsKKwkgICAgICB9CiAJICB9CiAKKwkvKiBNYWtlIHN1cmUgYm90aCBocCBhbmQgaHAyIGFy ZSBkZWZpbmVkICovCisJYXNzZXJ0KChocCAhPSBOVUxMKSAmJiAoaHAyICE9IE5VTEwpKTsKKwog CWlmICgoaHAtPnJjb2RlICE9IE5PRVJST1IgfHwgbnRvaHMoaHAtPmFuY291bnQpID09IDApCiAJ ICAgICYmIChocDItPnJjb2RlICE9IE5PRVJST1IgfHwgbnRvaHMoaHAyLT5hbmNvdW50KSA9PSAw KSkgewogI2lmZGVmIERFQlVHCg== 6118 2011-12-19 03:22:00 +0000 2011-12-19 03:22:03 +0000 testcase for this bug testglibcbug.c text/plain 308 fherrera I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 bmV0ZGIuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgoKaW50IG1haW4gKCkKewoJc3RydWN0IGFkZHJp bmZvICpyZXMsIGhpbnRzOwoKICAgICAgICBtZW1zZXQoJmhpbnRzLCAwLCBzaXplb2YoaGludHMp KTsKCWhpbnRzLmFpX2ZsYWdzIHw9IEFJX0FERFJDT05GSUc7CgloaW50cy5haV9zb2NrdHlwZSA9 IFNPQ0tfU1RSRUFNOwoKCWdldGFkZHJpbmZvICgiYnVzY29uLnJhZS5lcyIsIE5VTEwsICZoaW50 cywgJnJlcyk7CglyZXR1cm4gMDsKfQo=