This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/2499] dns_getcanonname() unaligned problems
- From: "david dot mckay at st dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 8 May 2006 14:03:10 -0000
- Subject: [Bug libc/2499] dns_getcanonname() unaligned problems
- References: <20060331175255.2499.david.mckay@st.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.