Re: Possible race in pserver leading to broken pipe error?

[Larry Jones]

Derek Robert Price writes:
> 
> Except the close-on-exec flag isn't shared.  And closing one dup'd file
> descriptor does not close the other.  My man pages and what I could find
> via the recent opengroup link you sent, only list the close-on-exec flag
> as being maintained separately.  Is there anything else?

I don't think so.

-Larry Jones

I don't like these stories with morals. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: cvs make problem on DEC alpha building rcs.c

[Miller Dale C Contr AFWA/SDHS]

Larry,
Thank you for your quick reply.  Adding "(VOID *)" to MAP_FAILED worked.
I will check if an updated sys/mman.h is available for our DEC alpha 4.0
systems.  Thanks again, 
Dale Miller

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 10, 2004 4:34 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: cvs make problem on DEC alpha building rcs.c

Miller Dale C Contr AFWA/SDHS writes:
> 
> source='rcs.c' object='rcs.o' libtool=no  depfile='.deps/rcs.Po'
>   tmpdepfile='.deps/rcs.TPo'  depmode=tru64 /bin/sh ../depcomp  
>   cc -std1 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../diff -I../zlib
>   -g -c `test -f 'rcs.c' || echo './'`rcs.c
> cc: Error: rcs.c, line 1027: In this statement, "rcsbuf_buffer" and
> "(-1)" 
>  may not be compared for equality or inequality.
> if ( rcsbuf_buffer == NULL || rcsbuf_buffer == MAP_FAILED )

It appears that your  header file is defective in that it
doesn't work correctly in ANSI C mode.  I suggest you complain to your
vendor and see if they have a fix available.  In the meantime, you can
probably circumvent the problem by changing "MAP_FAILED" in the above
line to "(void *)MAP_FAILED".

-Larry Jones

Some people just don't have inquisitive minds. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones wrote:

>Just to reinforce the concept one more time (at the risk of beating a
>dead horse), descriptors don't have buffers and thus don't need to be
>flushed; *streams* have buffers and need to be flushed; closing a stream
>also flushes it.  It's impolite at best to muck about with a stream's
>descriptor without at least asking its permission first.  And it's
>highly impolite to take a descriptor away (by closing it) from a stream
>that's still using it.


Okay, thanks.  I think I have it now, except for the bit about dup().

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAKmzoLD1OTBfyMaQRAmV1AJ0R2CjqAtMiej0Nith5cB8XRcwU4gCfdR4o
CsNmHUOsJnHu3gWfsGG39Po=
=hHqZ
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones wrote:

>On the contrary, dup() just gives you another handle to the same open
>file description -- the modes, pointers, etc. are *shared* by both fds.
>To get independence, you have to open the file again.


Except the close-on-exec flag isn't shared.  And closing one dup'd file
descriptor does not close the other.  My man pages and what I could find
via the recent opengroup link you sent, only list the close-on-exec flag
as being maintained separately.  Is there anything else?

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAKmzdLD1OTBfyMaQRAjyOAJ9dNvQ9ccvzlSF3Okpe6BEZ2ZDpggCg0Tr6
w9+3cRcLMcIS8WWMlM9HCJs=
=XPFD
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones wrote:

>



Thanks.  That was interesting.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAKmtgLD1OTBfyMaQRAjNZAJ0Z92G6rSl9UCGh3/Wk+y0SAb/iDQCfQxeh
ID+cZyPbUK15MPgC8CkgSOc=
=ZMl/
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Larry Jones]

Derek Robert Price writes:
> 
> Okay... I had just made the assumption that all the descriptors would
> need to be flushed before close if one had, but I see what you are
> getting at now.  The stdout stream had been used and has its own buffer
> so I needed to flush the stdout buf, and similarly the stderr buf, but
> not the descriptors.

Just to reinforce the concept one more time (at the risk of beating a
dead horse), descriptors don't have buffers and thus don't need to be
flushed; *streams* have buffers and need to be flushed; closing a stream
also flushes it.  It's impolite at best to muck about with a stream's
descriptor without at least asking its permission first.  And it's
highly impolite to take a descriptor away (by closing it) from a stream
that's still using it.

-Larry Jones

This game lends itself to certain abuses. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Larry Jones]

Derek Robert Price writes:
> 
> It's been awhile since I played concurrently with descriptors and
> streams, but I thought I recalled that the only real issue was that they
> were using the same descriptor, so operations on one affected the other,
> as opposed to a dup() of a file descriptor, which keeps track of two
> sets of data about the file, two modes, two pointers, etc.

On the contrary, dup() just gives you another handle to the same open
file description -- the modes, pointers, etc. are *shared* by both fds. 
To get independence, you have to open the file again.

-Larry Jones

I can feel my brain beginning to atrophy already. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Larry Jones]

Steve McIntyre writes:
> 
> fsync() or fdatasync() should do what you want here. Although you
> _should_ be able to mix stream and fd operations normally - stdio is
> meant to do the right thing AFAIK. But now I can't find the reference
> I had that said so, of course.

On the contrary, stdio expects to have exclusive control of the fd so
you have to be very careful when that isn't the case to keep things from
getting out of sync and producing undefined behavior.  There's a
discussion in the current Posix spec about the interaction and what you
have to do to make things work right:



In this particular case -- close()ing the fd underlying a stream --
there is at least one implementation where that causes the program to
crash when the stream is later closed (either explicitly or implicitly
when the program ends) which tries to close the fd again.

-Larry Jones

I've never seen a sled catch fire before. -- Hobbes


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Followup to 1.12.[4-5] waiting on lock core dump

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I took a look on Monday.  I think I was most of the way to having the
problem solved but I had to deal with a few other issues first.  I hope
to have it fixed and perhaps 1.11.13 & 1.12.6 releases by Friday.

Mark wrote:

>Just wondering if anyone had a chance to look into this yet. We
>have upgraded to 1.12.3, but can't go higher do to the server
>core dumping on race condition of loser of competing commits for
>a lock in a directory. I had provided -ttt and core trace output.
>
>Thanks,
>
>Mark
>
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&edition=us&threadm=fa.jnjbe53.95oghl%40ifi.uio.no&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26edition%3Dus%26q%3Dcm_mark%2540yahoo.com%2Bcore%2Bdump%26sa%3DN%26tab%3Dwg
>
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&edition=us&threadm=mailman.552.1074021212.928.info-cvs%40gnu.org&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26edition%3Dus%26q%3Dwaiting%2Bon%2Block%2Bcore%2Bdump%26btnG%3DGoogle%2BSearch
>
>(core trace)
>http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00060.html


Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAKlJ5LD1OTBfyMaQRAoudAKCyhZotTOZ//PHbO0n2kVpETy08wwCfULpG
/mFbwuj5VNkKyIarivFgES0=
=jP+3
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Possible race in pserver leading to broken pipe error?

[Derek Robert Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Siegerman wrote:

>On Tue, Feb 10, 2004 at 07:23:43PM -0500, Derek Robert Price wrote:
>
>>Larry Jones wrote:
>>
>>>fflush()/close() is a no-no -- you want fclose() instead.
>>
>>I couldn't find a man page for a file
>>descriptor flush -
>
>
>There isn't one, especially not for pipes.  AFAIK, as soon as
>you've written data into a pipe with write(), it's immediately
>available for read() without further (necessary or possible)
>action on your part.  (For regular files there's fsync(), as
>already mentioned, but that's sort of different, in that the
>flushing it does is transparent to user processes under all
>normal circumstances; for sockets there's shutdown(), which looks
>sort of half-way between a flush and a close.)
>
>>is there some way I could have flushed the pipe
>>without attaching the stream?
>
>
>You mean protocol_pipe?  It shouldn't be necessary.  The buffer
>that fflush() flushes is only created by fdopen(), so the
>combination is a no-op.


Okay... I had just made the assumption that all the descriptors would
need to be flushed before close if one had, but I see what you are
getting at now.  The stdout stream had been used and has its own buffer
so I needed to flush the stdout buf, and similarly the stderr buf, but
not the descriptors.

>All I think Larry's saying is, "use 'fflush ... fclose' instead
>of 'fflush ... close'".  The former sequence gives the userland
>stdio layer a chance to clean up everything it needs to clean up,
>whereas the latter sequence assumes that stdio has no cleanup to
>do in the first place.  That might well be a correct assumption
>on many systems, but it's probably unsafe to count on it.


Actually, it apparently isn't safe - the problem I ran into was that
closing the stdout descriptor and not the stream lost some data.

>In fact, I believe you could get away with just fclose()'s, with
>no fflush()'s at all.  close() without fflush(), on the other
>hand, you know about...  That is:
>fclose(stderr);
>fclose(stdout);
>close(protocol_pipe[1]);
>
>Two other comments:
>  - Typo in the comment for set_block_fd() -- s/non-//
>* Set buffer FD to non-blocking I/O.  Returns 0 for success or
errno
>* code.
>
>  - Maybe I'm being overly pedantic, but the last bit of new
>code, which drains flowcontrol_pipe, only does so if it
>succeeds in setting the descriptor to blocking mode.  If that
>attempt fails, you could drain the pipe anyway; it'd be a
>busywait loop, but that seems safer than doing nothing.
>Something like this (untested):
>
>char junk;
>ssize_t status;
>while ((status=read (flowcontrol_pipe[0], &junk, 1)) > 0
>|| (status == -1 && errno == EAGAIN));


I've made these changes and removed the set_block_fd() function
completely as it is no longer needed.

Thanks.  Testing these changes now but things look good and I should
commit it soon.

Derek

- --
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at !
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAKk3VLD1OTBfyMaQRAtpkAKCDhMjbX2Qqgeyn8ACPevNT2DJt7gCfUdCG
4WOOKMAFx5a4ABNsgJ/vLUA=
=AKf/
-END PGP SIGNATURE-




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs