> > I have following problem: I've downloaded latest curl and the very simple
> > program at the bottom of this mail crashes regularly on older redhats (6.0
> > with glibc-2.2.4-19 and 7.3 with glibc-2.2.5-notsure). It works ok with
> > RedHat 8.
>
> Does it always crash on the same host name? If yes, is it anything special
> with it?

yes on both systems. it's that imgt.cnusc.fr:8104. I don't know if that's
special but probably not.

> > I guess this is a glibc problem. Is there any workaround? The program I'm
> > developing MUST run on a plain RedHat 7.x systems, but I would like to make
> > use of libcurl...
>
> > #2 0x4023f6a0 in __gethostbyname_r (name=0x806e0a8 "imgt.cnusc.fr",
> > resbuf=0x8080980, buffer=0x8080994 "\177", buflen=22180,
> > result=0xbffff6b4, h_errnop=0xbffff6b8) at ../nss/getXXbyYY_r.c:200
> > #3 0x4001d0e6 in my_getaddrinfo (data=0x8050e78,
> > hostname=0x806e0a8 "imgt.cnusc.fr", port=8104, bufp=0xbffff6f4)
> > at hostip.c:619
>
> I think I know what might be causing this problem and I'd like to ask you to
> try a few tweaks:
>
> Watch the 'buflen' argument to gethostbyname_r() above. It is obscenely large
> and it should in fact never grow beyond 9000 bytes (CURL_NAMELOOKUP_SIZE).

I'm very sorry, but I'm not an gdb guru. More detailed instruction
please...

> This is a bug which can be corrected by replacing a while(1) with
> while(step_size <= CURL_NAMELOOKUP_SIZE) in lib/hostip.c (line 635 in the
> 7.10.2 version).
>
> But, it should never reach that far since it should've given up since long
> before that. I suspect that my "fix" to get Redhat 8.0 to work might've
> accidentally broken earlier versions. If this is the case, I'll get a
> headache. To test if this is the case, don't apply the fix I mentioned above
> but instead you change the error-check on line 630 to not check for the
> EAGAIN error. The EAGAIN error *SHOULD NOT* be returned for a too small
> buffer size, but is what the redhat 8.0 (glibc 2.2.93) version of
> gethostbyname_r() does.

I'm sorry but I'm currently too busy to help you hacking on this. I've put
that urls to http://vojta.pohoda.cz/curlbug.txt if you want to check it
yourself. If you were not able to reproduce this on your systems, I would
gladly participate, but no sooner then on wednesday... the project I was
working on now uses different library :( But I personally still think curl
is the best :)

Vojta

> It may very well be so that earlier versions sometimes return EAGAIN for some
> kind of error and then we should not retry the name resolve call with a
> larger buffer but we should instead bail out and return error.
>
> Let us know what happens.
>
>

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-12-08