Bug 23364
| Summary: | gethostbyaddr takes longer or locks up and burns cpu when linked to -pthread | ||
|---|---|---|---|
| Product: | Base System | Reporter: | chrisp <chrisp> |
| Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Does this problem still occur with more recent releases? I can't reproduce it with FreeBSD 4.4. Adding a reply I had forgotten about to the audit trail: In message <5.1.0.14.2.20011120112559.04ae0bb0@ball>, Chris Pugmire writes: > >At 08:11 AM 11/18/01 -0800, you wrote: >>Synopsis: gethostbyaddr takes longer or locks up and burns cpu when linked >>to -pthread >> >>State-Changed-From-To: open->feedback >>State-Changed-By: iedowse >>State-Changed-When: Sun Nov 18 08:10:21 PST 2001 >>State-Changed-Why: >> >>Does this problem still occur with more recent releases? I can't >>reproduce it with FreeBSD 4.4. >> >>http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23364 > >Hi, sorry I'm unable to reproduce it now, it originally occured on a customers >machine which I no longer have access to, I can't make it occur on our own >system now but I don't know if I ever reproduced it locally, it may be >dependent >in some way on the dns server used I'm not sure. > >Sorry this isn't very helpful, all I can suggest is you check the code that >reads from the dns server to see if it can in any way loop while waiting for >a response, my guess would be if the thread library is somehow stopping a >select >call from working correctly but it must be more subtle than that. > >Thanks for looking into it anyway I appreciate it. It was several months >ago I reported this so sorry if I'm a bit shaky on the facts. > > ChrisP. > This bug (if it really happened) may have been fixed by the fix to bin/42175: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/23364 It may have only happened when you configured /etc/resolv.conf to have an unreachable nameserver, so that the UDP query socket got an error such as ENETDOWN or something like that. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com State Changed From-To: feedback->closed According to Archie Cobbs, this is probably the same problem as that in bin/42175, which has been fixed. |
With a test program doing ip number to name lookups for a number that does not have an entry if the program is linked with -pthread then it takes 30 seconds longer and burns 100% cpu until it times out. I believe it sometimes never times out or takes much longer but cannot reproduce this in a test case. Note that no actual threads are used, this program is simply linked with -pthread and then behaves in this odd way. How-To-Repeat: Sample code included: (include headers...) int do_reverse(char *ipnum); int main(int argc, char *argv[]) { int i; if (argc<2) { usage: printf("Usage: testdns -rev n.n.n.n\n"); return 0; } tcp_startup(); for (i=1; i<argc; i++) { if (strncmp(argv[i],"-rev",4)==0) { do_reverse(argv[++i]); } else { printf("Invalid option (%s)\n",argv[i]); goto usage; } } return 0; } int do_reverse(char *ipnum) { struct sockaddr_in sin; struct hostent *hp; int start; start = time(NULL); sin.sin_addr.s_addr = inet_addr(ipnum); printf("Looking up (%s)\n",ipnum); hp = gethostbyaddr( (char *) &(sin.sin_addr), sizeof(sin.sin_addr), AF_INET); printf("Result %p\n",hp); if (hp!=NULL) if (hp->h_name!=NULL) { printf("result (%s)\n",hp->h_name); } printf("Delay %d seconds\n",time(NULL)-start); return TRUE; } Example output with the same program linked different ways: news# ./testdns_nopthread -rev 160.79.54.12 Looking up (160.79.54.12) Result 0x0 Delay 80 seconds news# ./testdns_pthread -rev 160.79.54.12 Looking up (160.79.54.12) Result 0x0 Delay 111 seconds (and in the second case watching top will show the testdns process burning cpu)