From owner-freebsd-bugs@FreeBSD.ORG Sat Jun 7 01:35:48 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D9437B401 for ; Sat, 7 Jun 2003 01:35:48 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F70043F75 for ; Sat, 7 Jun 2003 01:35:47 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h578ZiEU020641; Sat, 7 Jun 2003 10:35:45 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sat, 7 Jun 2003 10:35:44 +0200 (CEST) From: Martin Blapp To: Mike Romberg Message-ID: <20030607101200.W44942@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org Subject: Re: rpc/svc_tcp.c (readtcp) calls svc_getreqset2 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2003 08:35:48 -0000 Hi, Please write the next time to freebsd-questions@freebsd.org or freebsd-hackers@freebsd.org. This is definitly not a freebsd bug :) > I'm attempting to port some code to a mac running os x. From what I >have found on the net, it seems that os x uses a freebsd version of >the rpc libraries. I'm not sure if this is a bug or not. But it sure >readtcp has it's own select loop in it which can call >svc_getreqset2(). I think this was done for some kind of security >related problem (a DOS attack). Dawrin uses the ONC RPC version we have in FreeBSD 4. In FreeBSD 5 we use now TIRPC, which has now non-blocking behaviour, also to prevent some sort of DOS attack ( you can telnet to port 111 or the port used by your rpc server and deadlock it for 35 seconds each time with just two or three returns) >My application is an rpc server which is not threaded and is in no >way prepared to deal with serving multiple requests at the same time. >In fact it likes to dump core when this happens. The select loop in >my code calls svc_getreqset() to process file descriptors that are >ready. And then while doing the xdr processing for a single request, >readtcp() is calling svc_getreqset2() and starting the dispatching of >another request. This ends up causing my application to dump core >because it is in the middle of one transaction when another starts. > > As far as I know, an RPC implementation is not supposed to do this. >I'm wondering if there is some sort of workaround short of threading >my application (which would be a big change)? Or is this a known bug? Are you sure apple had this last fix in it's darwin codebase ? It really sounds like you ar hit by this old bug. Go and check ;-) http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/rpc/Attic/svc_tcp.c.diff?r1=1.18&r2=1.18.2.1 >We have been running this patch on a production NIS server for 2.5 weeks now. >Normally we would have ypserv die at least once a week, and often many times >a day. > >This patch treats and error from select as zeroing out the FD_SET to indicate >that no fds are ready for reading. This is safe because the rpc code >always re-inits the FDSET before calling select. --- src/lib/libc/rpc/Attic/svc_tcp.c 2000/01/27 23:06:41 1.18 +++ src/lib/libc/rpc/Attic/svc_tcp.c 2001/03/08 14:04:42 1.18.2.1 @@ -352,6 +352,7 @@ readtcp(xprt, buf, len) tv = delta; /* in case select() implements writeback */ switch (select(svc_maxfd + 1, fds, NULL, NULL, &tv)) { case -1: + FD_ZERO(fds); if (errno != EINTR) goto fatal_err; gettimeofday(&tmp1, NULL); Martin