gethotbyname error continued

[Jerry Feldman]

First, you have a very predictable occurrence. I think you have eliminated 
sethostent()/endhostent() issues, although I'd still retain them. 
One thing you should look at is the actual host name being passed to the 
call. could it be that somehow servername is being corrupted, and 
gethostbyname is actually doing the correct thing. 

One easy way to check is to write a function that reads the /etc/host file 
line by line, remove comments, then just do a 
strstr( hoststring, servername);

If you get a match, then you can probably look at gethostbyname() as the 
culprit. If it fails, then servername is probably corrupt. In my 
experience, I've found that there are a lot of latent bugs in many 
programs. I was responsible for a number of development environment tools 
for Digital Unix (eg. Tru64). At one point, one of the utilities (cflow or 
cxref) started segfaulting when using the latest compiler. Looking at the 
source I found that the code had not been touched since porting from OSF1 
to Digital Unix, and that was simply a checkin to source control. There was 
a latent bug that had never before been exposed until the new compiler 
exposed it as a result of an optimization. 

Again, I would write a small test program to simulate the failure. I'm not 
sure how many different servers that you have, but use all their names. 

On 18 Jun 2002 at 19:52, Frank Ramsay wrote:

> It is hitting gethostbyname (I put in printfs to be sure sure) and I tried 
> changing the sethostent(0) to sethostent(1) and it didn't help
> BUT
> I've discovered that it stops working on the 1022n'd call _every time_
> (I removed the sleep in the main loop to get it to run faster) And that is 
> very strange and I'm wondering if it's a bug in the library itself.
>
--
Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9