From: Dan Kegel <dkegel@ixiacom.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: michael <michael@newdream.net>, NFS List <nfs@lists.sourceforge.net>
Subject: Re: more statd segfault
Date: Fri, 12 Sep 2003 13:21:09 -0700 [thread overview]
Message-ID: <3F622AB5.3010501@ixiacom.com> (raw)
In-Reply-To: <16225.27156.281198.45769@notabene.cse.unsw.edu.au>
Neil Brown wrote:
> On Thursday September 11, michael@newdream.net wrote:
>
>>I finally tracked down the statd segfault that had been plaguing me for
>>sometime.
>>
>>statd calls sunrpc code which is in libc on debian. this code loops
>>through all possible file descriptors and in my case if the number of
>>fds per process is set higher then 8096 it segfaults.
>
>
> Well done.
> I have just applied a patch to statd and mountd in nfs-utils so that
> it forces the fd limit down to FD_SETSIZE if it is above that. This
> appears to effectively work around what is really a libc bug (I
> think).
>
> Have you reported it to the glibc maintainers?
I was curious, so I grepped for references to fd_set and FD_SETSIZE in glibc-2.3.2.
Looks like the rpc code actually exports an fd_set to the world!
Sad to have FD_SETSIZE show up in the interface like that.
(Looks like H.J. Lu had some interest in this code; see
http://sources.redhat.com/ml/libc-alpha/2001-05/msg00071.html)
Here are the hits of interest.
glibc-2.3.2/ChangeLog.11: [_LIBC]: Fully reinstate the code that avoids the FD_SETSIZE limit
glibc-2.3.2/ChangeLog.12: (rpc_thread_multi, __rpc_thread_svc_fdset, __rpc_thread_createerr,
glibc-2.3.2/ChangeLog.12: * include/rpc/rpc.h: Remove svc_fdset, rpc_createerr, svc_pollfd, and
glibc-2.3.2/ChangeLog.12: * sunrpc/rpc/rpc.h: Declare __rpc_thread_svc_fdset,
glibc-2.3.2/ChangeLog.12: Define svc_fdset, get_rpc_createerr, svc_pollfd, and
glibc-2.3.2/ChangeLog.12: Define __rpc_thread_svc_fdset, __rpc_thread_createerr,
glibc-2.3.2/ChangeLog.12: * sunrpc/Versions [libc] (GLIBC_2.2.3): Export __rpc_thread_svc_fdset,
glibc-2.3.2/FAQ.in:only place where OPEN_MAX and FD_SETSIZE is really needed in the library
glibc-2.3.2/FAQ.in:itself is the size of fd_set which is used by select.
glibc-2.3.2/FAQ.in:limits imposed by the `fd_set' type. Instead all places where the
glibc-2.3.2/FAQ.in:prominent example is `struct fd_set'.
glibc-2.3.2/INTERFACE:svc_fdset svc_fdset
glibc-2.3.2/include/rpc/rpc.h: fd_set svc_fdset_s; /* Global, rpc_common.c */
glibc-2.3.2/include/rpc/rpc.h:libc_hidden_proto (__rpc_thread_svc_fdset)
glibc-2.3.2/include/rpc/svc.h:extern void svc_getreqset_internal (fd_set *__readfds) attribute_hidden;
glibc-2.3.2/sunrpc/Versions: rpc_createerr; svc_fdset; svcauthdes_stats;
glibc-2.3.2/sunrpc/Versions: __rpc_thread_svc_fdset; __rpc_thread_createerr;
glibc-2.3.2/sunrpc/rpc/rpc.h:extern fd_set *__rpc_thread_svc_fdset (void) __attribute__ ((__const__));
glibc-2.3.2/sunrpc/rpc/rpc.h:#define svc_fdset (*__rpc_thread_svc_fdset ())
glibc-2.3.2/sunrpc/rpc/svc.h:extern fd_set svc_fdset;
glibc-2.3.2/sunrpc/rpc/svc.h:#define svc_fds svc_fdset.fds_bits[0] /* compatibility */
glibc-2.3.2/sunrpc/rpc/svc.h:extern void svc_getreqset (fd_set *__readfds) __THROW;
glibc-2.3.2/sunrpc/rpc_common.c:#undef svc_fdset
glibc-2.3.2/sunrpc/rpc_common.c:fd_set svc_fdset;
glibc-2.3.2/sunrpc/rpc_svcout.c: f_print (fout, "\t\textern fd_set svc_fdset;\n");
glibc-2.3.2/sunrpc/rpc_svcout.c: f_print (fout, "\t\t\tif (FD_ISSET(i, &svc_fdset))\n");
glibc-2.3.2/sunrpc/rpc_thread.c:#undef svc_fdset
glibc-2.3.2/sunrpc/rpc_thread.c:fd_set *
glibc-2.3.2/sunrpc/rpc_thread.c:__rpc_thread_svc_fdset (void)
glibc-2.3.2/sunrpc/rpc_thread.c: return &svc_fdset;
glibc-2.3.2/sunrpc/rpc_thread.c: return &tvp->svc_fdset_s;
glibc-2.3.2/sunrpc/rpc_thread.c:libc_hidden_def (__rpc_thread_svc_fdset)
glibc-2.3.2/sunrpc/svc.c: if (sock < FD_SETSIZE)
glibc-2.3.2/sunrpc/svc.c: FD_SET (sock, &svc_fdset);
glibc-2.3.2/sunrpc/svc.c: if (sock < FD_SETSIZE)
glibc-2.3.2/sunrpc/svc.c: FD_CLR (sock, &svc_fdset);
glibc-2.3.2/sunrpc/svc.c: fd_set readfds;
glibc-2.3.2/sunrpc/svc.c:svc_getreqset (fd_set *readfds)
- Dan
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2003-09-12 20:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-08 19:58 more statd segfault michael
2003-09-12 2:05 ` michael
2003-09-12 6:39 ` Neil Brown
2003-09-12 20:21 ` Dan Kegel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F622AB5.3010501@ixiacom.com \
--to=dkegel@ixiacom.com \
--cc=michael@newdream.net \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox