Bug 122469 - TCP socket dissapears from RPC's svc_fdset
TCP socket dissapears from RPC's svc_fdset
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-04 17:26 EDT by Steven Emmerson
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 07:02:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
compressed tar(1)-file of skeletal problem package (18.23 KB, application/octet-stream)
2004-05-04 17:32 EDT, Steven Emmerson
no flags Details
compressed tar(1)-file of problem-exhibiting test code (14.07 KB, application/octet-stream)
2004-05-14 18:16 EDT, Steven Emmerson
no flags Details

  None (edit)
Description Steven Emmerson 2004-05-04 17:26:13 EDT
Description of problem:

A TCP socket episodically dissapears from RPC's server-side svc_fdset
variable.


Version-Release number of selected component (if applicable):

libc-2.3.2.so


How reproducible:

Attached demonstration package fails approximately 3 out of 4 times.


Steps to Reproduce:

1. Unpack attached package.
2. See file README_Fedora.
Comment 1 Steven Emmerson 2004-05-04 17:32:26 EDT
Created attachment 99968 [details]
compressed tar(1)-file of skeletal problem package

See the file README_Fedora
Comment 2 Jakub Jelinek 2004-05-14 12:01:47 EDT
First of all, please note that having side effects in assert ()
macros is very bad idea.

The TCP socket can disappear from svc_fdset during xprt destroy,
which can happen if the xprt_stat is XPRT_DIED.
That can happen if the sender and receiver get out of sync, usually
because an application error.
I'm not willing to debug your code for you.
If even after debugging you still think there is a bug in glibc,
please make really small testcase and explain in detail where do
you think glibc sunrpc starts misbehaving.
Comment 3 Steven Emmerson 2004-05-14 18:13:01 EDT
Regarding side-effects in assert()s: I'll upload a new version that
doesn't have side-effects in assert()s.  It exhibits the same failure
mode.

Regarding the TCP socket disappearing from svc_fdset during "xprt
destroy": I'm not sure what you mean by that because I'm not
destroying the RPC transport when the socket disappears.

Regarding the sender and receiver getting out of sync: I believe
you've correctly identified the problem with the networking layer.

Regarding debugging my code: I don't believe it needs to be debugged.
 The uploaded code is a very, very small subset of a much larger
program that's been used operationally since about 1994 (at least in
one version or another).  The program distributes quasi-realtime data
via the Internet hundreds of sites around the world.  The program is
THE top advanced application on Internet2.  The uploaded code runs
well under SunOS, HP-UX, IRIX, and FreeBSD and ran well under Linux
and AIX until recently.
Comment 4 Steven Emmerson 2004-05-14 18:16:09 EDT
Created attachment 100242 [details]
compressed tar(1)-file of problem-exhibiting test code

Has side-effects in assert(3)s removed.
Comment 5 Ulrich Drepper 2004-09-30 07:02:27 EDT
RPC implementations differ.  Period.  There is no standard.  If you
think something should be changed, suggest a change.  As Jakub said,
we are not debugging your code and see where it makes assumptions
which differ from what glibc currently does.  The best you can do is
to drop RPC and use something sane.

If you have a concrete description of the change you'd like to see,
you can reopen the bug.

Note You need to log in before you can comment on or make changes to this bug.