I have this serious problem with a file descriptor that for some
unknown reason suddenly goes bad when I read from it or write to it.
Is there some sort of call I can make that will tell me more about
what's wrong with this descriptor than just what errno says?
    When I call any one of read(), write() or select() on it, -1 is
returned and errno is set to EBADF. However, I've been able to call
several other functions on it that don't have that problem, such as
fstat(), fcntl(), and setsockopt() to name a few.

    The descriptor is an AF_INET socket, passed from one process to
another via SCM_RIGHTS. If the sending process uses the socket there
is no problem. However, if I run lsof before the descriptor goes bad,
the receiving process is listed as having this open descriptor, with
read/write permission. I've been through all the code tediously, I've
checked it against other people's code fragments, and examined the
returns of fstat() and fcntl(), and they all tell me that this
descriptor is what it is supposed to be. How do I find out more?

Jo wrote:

> I have this serious problem with a file descriptor that for some
> unknown reason suddenly goes bad when I read from it or write to it.
> Is there some sort of call I can make that will tell me more about
> what's wrong with this descriptor than just what errno says?
>     When I call any one of read(), write() or select() on it, -1 is
> returned and errno is set to EBADF. However, I've been able to call
> several other functions on it that don't have that problem, such as
> fstat(), fcntl(), and setsockopt() to name a few.

Just a guess but do you fork and does the child then either exit or close
the fd. There are IIRC some subtle issues involved here.

Check from within your process that /proc/self/fd lists the file descriptor
just before your problematic read, write or select...

HTH.
Regards, Dan.
-- 
** The email address  *IS*  valid, do  NOT  remove the spamblock
And on the evening of the first day the lord said...........
..... LX 1, GO!; and there was light.

Dan Mills <dmills@spamblock.demon.co.uk> wrote in message news:<cjkh79$b33$1$830fa79d@news.demon.co.uk>...
> Jo wrote:
> 
> > I have this serious problem with a file descriptor that for some
> > unknown reason suddenly goes bad when I read from it or write to it.
> > Is there some sort of call I can make that will tell me more about
> > what's wrong with this descriptor than just what errno says?
> >     When I call any one of read(), write() or select() on it, -1 is
> > returned and errno is set to EBADF. However, I've been able to call
> > several other functions on it that don't have that problem, such as
> > fstat(), fcntl(), and setsockopt() to name a few.
> 
> Just a guess but do you fork and does the child then either exit or close
> the fd. There are IIRC some subtle issues involved here.

   Yes, the process that receives the socket is a child of the sender.
The fork happens before the creation of the socket. As for closing the
descriptor, the child does different things; I don't really pay
attention to what, but it certainly doesn't close the descriptor
before the problem occurs.

> 
> Check from within your process that /proc/self/fd lists the file descriptor
> just before your problematic read, write or select...

   Ok, here's a piece of what I got back:
lrwx------  1 jo users 64 Oct  2 01:24 4 -> socket:[9124]
l-wx------  1 jo users 64 Oct  2 01:24 5 -> pipe:[8962]
lrwx------  1 jo users 64 Oct  2 01:24 6 -> socket:[8963]
lr-x------  1 jo users 64 Oct  2 01:24 7 -> /proc/4881/fd

The descriptor is 4, so I guess that's the first one. There is a
pipe() opened with the parent, and a socketpair(). I guess those are
the next 2. The process number of the child is 4770, FWIW. Was it a
mistake to use a system() call to get the dir listing? I'm guessing
that 4881 is the process number of the forked ls call.

Kasper Dupont <kasperd@daimi.au.dk> wrote:

>Dan Mills wrote:
>> 
>> Just a guess but do you fork and does the child then either exit or close
>> the fd. There are IIRC some subtle issues involved here.
>
>That shouldn't cause any trouble. A shutdown call
>on the socket might explain the problem.

	Please, tell me more! I'm dyin' here!

Jo wrote:
> 
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
> 
> >That shouldn't cause any trouble. A shutdown call
> >on the socket might explain the problem.
> 
>         Please, tell me more! I'm dyin' here!

The shutdown system call will close the socket for
communication in one or both directions. It operates
on the socket, not the file descriptor. That means
it affects all processes with file descriptors for
that socket. Unlike close, that will only affect the
process calling it, but any other process with a
file descriptor for the socket can keep using it.

Do you have a shutdown() call anywhere in your code,
or are you perhaps calling some system calls or
executables, which may use shutdown()

See: man 2 shutdown

(Don't confuse shutdown(2) and shutdown(8))

-- 
Kasper Dupont

It was a dark and stormy night when Kasper Dupont
<kasperd@daimi.au.dk> wrote:

>Jo wrote:
>> 
>> Kasper Dupont <kasperd@daimi.au.dk> wrote:
>> 
>> >That shouldn't cause any trouble. A shutdown call
>> >on the socket might explain the problem.
>> 
>>         Please, tell me more! I'm dyin' here!
>
>The shutdown system call will close the socket for
>communication in one or both directions. It operates
>on the socket, not the file descriptor. That means
>it affects all processes with file descriptors for
>that socket. Unlike close, that will only affect the
>process calling it, but any other process with a
>file descriptor for the socket can keep using it.
>
>Do you have a shutdown() call anywhere in your code,
>or are you perhaps calling some system calls or
>executables, which may use shutdown()
>
>See: man 2 shutdown
>
>(Don't confuse shutdown(2) and shutdown(8))
	Ah yes, that. No, shutdown is nowhere in any of my code. I
wouldn't have heard of it if you hadn't told me..
	But an older thread I started seems to have picked up:
Descriptor passed w/SCM_RIGHTS is invalid. Check it out.