From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11942 invoked by alias); 23 Jun 2011 16:51:15 -0000 Received: (qmail 11931 invoked by uid 22791); 23 Jun 2011 16:51:13 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,SARE_SUB_FOREVER,TW_CV X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 16:50:59 +0000 From: "ppluzhnikov at google dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12926] New: getaddrinfo()/make_request() may spin forever X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ppluzhnikov at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 23 Jun 2011 16:51:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00073.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12926 Summary: getaddrinfo()/make_request() may spin forever Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: ppluzhnikov@google.com I am not sure whether this is a kernel bug or a glibc bug. Even if it is a kernel bug, it might be wise to fix it in glibc, since buggy kernels are observed "in the wild". Over last two weeks, we observed several Java programs that have a thread spinning here: #0 0xf7717430 in __kernel_vsyscall () #1 0xf757e448 in recvmsg () at ../sysdeps/unix/sysv/linux/i386/socket.S:97 #2 0xf76797a6 in make_request (fd=1590, pid=, seen_ipv4=0x7dceea7b, seen_ipv6=0x7dceea7a, in6ai=0x7dceea70, in6ailen=0x7dceea6c) at ../sysdeps/unix/sysv/linux/check_pf.c:123 #3 0xf7679bd4 in __check_pf (seen_ipv4=0x7dceea7b, seen_ipv6=0x7dceea7a, in6ai=0x7dceea70, in6ailen=0x7dceea6c) at ../sysdeps/unix/sysv/linux/check_pf.c:275 #4 0xf761ff4c in getaddrinfo (name=0x988f330 "", service=0x0, hints=0x7dceeaf8, pai=0x7dceeb18) at ../sysdeps/posix/getaddrinfo.c:2109 ... strace shows un-ending stream of recvmsg() calls, which all return 0. Looking in check_pf.c, it seems clear that if recvmsg() keeps returning 0, then the for() loop on line 131 (current git source) will not execute, and the do-while loop on line 113 will spin forever. We do not know what conditions provoke the kernel (2.6.34-smp and 2.6.26-smp have been observed) to return zero here, and the problem is not repeatable on the same machine. The following patch will make make_request() fail under these conditions. Not sure whether that's the right thing to do. diff --git a/sysdeps/unix/sysv/linux/check_pf.c b/sysdeps/unix/sysv/linux/check_pf.c index c053adc..47cf034 100644 --- a/sysdeps/unix/sysv/linux/check_pf.c +++ b/sysdeps/unix/sysv/linux/check_pf.c @@ -121,7 +121,7 @@ make_request (int fd, pid_t pid, bool *seen_ipv4, bool *seen_ipv6, }; ssize_t read_len = TEMP_FAILURE_RETRY (__recvmsg (fd, &msg, 0)); - if (read_len < 0) + if (read_len <= 0) goto out_fail; if (msg.msg_flags & MSG_TRUNC) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.