This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/2499] dns_getcanonname() unaligned problems


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]