I am using fdopen to associate a FILE with a socket descriptor. My
problem is this: if the socket is closed and I pass the FILE returned
from fdopen to fclose, my program dies with a memory fault.

My question: why do I get a memory fault with fclose when the socket
descriptor is closed and how can I prevent that?

TIA,
Jeff

[ Post a follow-up to this message ]

Jeff wrote :
quote:

> I am using fdopen to associate a FILE with a socket descriptor. My
> problem is this: if the socket is closed and I pass the FILE returned
> from fdopen to fclose, my program dies with a memory fault.
>
> My question: why do I get a memory fault with fclose when the socket
> descriptor is closed and how can I prevent that?


could you show us a minimal code so that we can point you on the error ?
fclose() should not make your program fails even if the stream is opened
with fdopen().

--
DINH V. Hoa,

etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan

[ Post a follow-up to this message ]

On Mon, 12 Jan 2004, Jeff wrote:
quote:

> I am using fdopen to associate a FILE with a socket descriptor. My
> problem is this: if the socket is closed and I pass the FILE returned
> from fdopen to fclose, my program dies with a memory fault.
>
> My question: why do I get a memory fault with fclose when the socket
> descriptor is closed and how can I prevent that?


Don't close the socket; let fclose() do it.  (Or perhaps clearer:
don't mix the standard I/O library with sockets.)

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

[ Post a follow-up to this message ]

On 2004-01-12, Rich Teer <rich.teer@rite-group.com> wrote:
quote:

> On Mon, 12 Jan 2004, Jeff wrote:
> 
>
> Don't close the socket; let fclose() do it.  (Or perhaps clearer:
> don't mix the standard I/O library with sockets.)
>


Good recommendation. But still, check your program for buffer overflows,
double free or any other type of memory corruption. Usually, when you see
that library functions cause segfault then either you are passing bad
arguments, or corrupting memory somewhere in your code.

Andrei

[ Post a follow-up to this message ]

Hi!
quote:

> could you show us a minimal code so that we can point you on the error ?
> fclose() should not make your program fails even if the stream is opened
> with fdopen().


I would also expect the behavior explained by Dinh. However, I checked what
SUSv3 is saying about that issue:

</copy-paste>

The fclose() function shall fail if:

[EBADF]
[CX] [Option Start] The file descriptor underlying stream is not valid.
[Option End]

</copy-paste>


This is a CX-extension, i.e. the 2001 revised version of the classical
Posix 1003.1.  Your system might not necessarily supports this
"quite recent" standard.

quote:
 
[QUOTE]
> Don't close the socket; let fclose() do it.  (Or perhaps clearer:
> don't mix the standard I/O library with sockets.)


Yes. IMHO, that's a good practical advise (may still, alas, hold a few
years)


Regards,
Loic.

--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web

[ Post a follow-up to this message ]

"Loic Domaigne" <loic-dev@gmx.net> wrote, on Tue, 13 Jan 2004:
quote:

> I checked what SUSv3 is saying about that issue:
>
> </copy-paste>
>
> The fclose() function shall fail if:
>
> [EBADF]
>     [CX] [Option Start] The file descriptor underlying stream is not
>     valid.
> [Option End]
>
> </copy-paste>
>
>
> This is a CX-extension, i.e. the 2001 revised version of the classical
> Posix 1003.1.  Your system might not necessarily supports this "quite
> recent" standard.


CX marks extensions to the C Standard, not extensions to the old POSIX.1.
(Perhaps you are confusing it with EX which was used in SUSv1 and SUSv2
to mark UNIX extensions to POSIX.1).

The original POSIX.1 required fclose() to set errno to EBADF *if* it
returned an error indication when the underlying fd was invalid.  This
meant that if there was any data in the buffer that needed flushing,
fclose() would have to fail with EBADF, but if there was no data to
flush then implementations could choose whether to have fclose() fail
with EBADF or successfully close the stream.  The only difference in
the new POSIX.1/SUSv3 is that returning an error indication in the
second case is mandatory instead of optional.

--
Geoff Clare <nospam@gclare.org.uk>

[ Post a follow-up to this message ]

Hello Geoff,
quote:
 
[QUOTE]
> CX marks extensions to the C Standard, not extensions to the old POSIX.1.
> (Perhaps you are confusing it with EX which was used in SUSv1 and SUSv2
> to mark UNIX extensions to POSIX.1).


No, actually I'm still learning SUSv3 and I try hard to become a seasonned
SUSler :^)

I think, I got it where my mistake was. Taken from the explanations
about [CX]:

<copy-paster>
[CX] Extension to the ISO C standard
The functionality described is an extension to the ISO C standard.
Application writers may make use of an extension as it is supported on all
IEEE Std 1003.1-2001-conforming systems.
</copy-paste>

it occurred to me that ISO C in question would be the ISO C99 and, yes,
I then messed up with the reference to Posix 1003.1-2001. (This § doesn't
say that it is an extension devised by Posix 1003.1-2001, but that system
conforming to that standard supports automatically [CX]).

So you would say that - modulo Jeff's code corectness - Jeff's platform
doesn't conform?


Thanks Geoff for your -as usual- sharp insights
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web

[ Post a follow-up to this message ]

"Loic Domaigne" <loic-dev@gmx.net> wrote, on Tue, 13 Jan 2004 21:58:05
+0000:
quote:

> So you would say that - modulo Jeff's code corectness - Jeff's platform
> doesn't conform?


Yes.  It doesn't even conform to the C Standard - assuming Jeff's code
has not done something that results in undefined behaviour - since the
C Standard requires fclose() either to return 0 or to return EOF, and
on Jeff's system the call in question does neither.

--
Geoff Clare <nospam@gclare.org.uk>

[ Post a follow-up to this message ]

Geoff Clare wrote:
quote:

>
> "Loic Domaigne" <loic-dev@gmx.net> wrote, on Tue, 13 Jan 2004 21:58:05
> +0000:
> 
>
> Yes.  It doesn't even conform to the C Standard - assuming Jeff's code
> has not done something that results in undefined behaviour - since the
> C Standard requires fclose() either to return 0 or to return EOF, and
> on Jeff's system the call in question does neither.


I don't think so.  Jeff has somehow closed the socket
"out from beneath" the associated FILE* descriptor.  In the
C Standard there is no way at all to do this, hence the
program has already departed from the Standard's guarantees.

How about this one:

FILE *stream = (FILE*) "Hello, world!";
fclose (stream);

Clearly, fclose() is not required to do anything sensible
in a case like this -- and I think Jeff's case is similar
in spirit.

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
quote:

>"Loic Domaigne" <loic-dev@gmx.net> wrote, on Tue, 13 Jan 2004 21:58:05
>+0000:

quote:
 
[QUOTE]
>Yes.  It doesn't even conform to the C Standard - assuming Jeff's code
>has not done something that results in undefined behaviour - since the
>C Standard requires fclose() either to return 0 or to return EOF, and
>on Jeff's system the call in question does neither.


If you pass it a valid FILE *; if you don't pass it a valid
FILE *, you get "undefined behaviour".

SEGV is completely acceptable as an implementation
of "undefined behaviour".

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]