public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "david dot mckay at st dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/2499] dns_getcanonname() unaligned problems Date: Mon, 08 May 2006 14:03:00 -0000 [thread overview] Message-ID: <20060508140310.24067.qmail@sourceware.org> (raw) In-Reply-To: <20060331175255.2499.david.mckay@st.com> ------- Additional Comments From david dot mckay at st dot com 2006-05-08 14:03 ------- (In reply to comment #2) > While the place you indicated indeed have problems, all the changes you > proposed > are wrong. Amazing. It also shows you never tested the changes. Yes, you are quite right, the patch is wrong. I misunderstood what ns_get16() does. Apologies. I did run it, and it appeared to solve the problem I had. Probably worked for the same reason the original code worked even though it was looking at the wrong data. > What interests me is how you came across the res_query.c problems. In all > the > years that we have this code I cannot remember seeing any indication that > this > was ever a problem. Yes, I was amazed that these bug have not been spotted before. I came across them quite easily. It was telnetd that caused the problem. Basically, I could not telnet in as it hit these bugs. The nasty thing was that on another machine running identical software I could. After some head scratching I realised the difference was the length of the target hostname, one had an odd number of chars and the other even. Even failed. The instruction trace from the simulator clearly showed up both problems easily. I looked at what happend on a superh, and that machine went through the error case as ntohs(hp->ancount)==0 happened to be true due to the stack layout, whereas the ST200 didn't. I suspect the stack may always be in a defined state when this function is called, and luck has dictated that it goes through the error case on most machines, which is why you would not have seen the resulting misaligned reported before. The unaligned accesses would not be seen on x86 of course, and would be fixed up by the kernel anyway on most arches. I chose to kill unaligned user accesses instead of fix them up for the ST200, which is why I saw it so obviously. A strange combination of problems I think. It would be interesting to figure out exactly what is going on on x86. The only vague hint that someone else may have seen this that I could find is: http://www.redhat.com/archives/fedora-desktop-list/2004-September/msg00031.html Where valgrind detects a conditional jump or move dependant on uninitialised value in the res_nquery() function. > I checked in correct changes upstream. Thanks. At least my analysis was right even if the patch wasn't:-) -- http://sourceware.org/bugzilla/show_bug.cgi?id=2499 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
prev parent reply other threads:[~2006-05-08 14:03 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-03-31 17:52 [Bug libc/2499] New: " david dot mckay at st dot com 2006-04-03 10:17 ` [Bug libc/2499] " david dot mckay at st dot com 2006-05-06 19:20 ` drepper at redhat dot com 2006-05-08 14:03 ` david dot mckay at st dot com [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20060508140310.24067.qmail@sourceware.org \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).