bug-rcs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug #41707: RCS 5.8 file corruption when using file descriptor IO fo


From: Achim Gratz
Subject: Re: bug #41707: RCS 5.8 file corruption when using file descriptor IO for large files
Date: Sun, 27 Jul 2014 17:49:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.91 (gnu/linux)

Thien-Thi Nguyen writes:
> - I have rewritten the test, attached here, to be more idiomatic.
>
>   The first step is to check that this test fails for you when
>   unpatched, and passes when patched.  Could you please confirm?
>   (NB the ??? re ‘need_subdir’.)  The "maybe" in the description
>   is because there was no way for 5.7 to force STDIO operation,
>   so the problem might have been latent at that time.

I'll check this, but at the moment can't say when I'll have time to do
that.  As for the subdir I don't think it matters since the first
version of my test didn't use it.  I'll test it again, though.

> - I'm wary of adding the close/re-open sequence unconditionally and
>   wonder if there is a way to detect systems that misbehave thusly
>   with a short C program (or better yet, sequence of shell
>   commands) to be run by the configure script.  What do you think?

I haven't had the time to reduce this to a deomstrator, but once we have
that it'd be possible to use the result in configure.

> - etc
>
> It's probably best to worry about "etc" after we surmount these
> first two steps.  I understand that there is a difference between
> GNU/Linux (say) and Cygwin, but i don't understand (yet) if that
> difference is legitimate (i.e., allowed by POSIX or other relevant
> standards).  What do you suggest i read to understand the analysis
> linked in the URL above?

I'm not sure what guarantees POSIX makes w.r.t. shared filehandles and
stream operations across a fork.  The conditions that trigger the bug
seem to be that one must have a stream associated to a filehandle,
already read from that stream so the buffer gets filled (and the stream
is unclean), then fork with that filehandle still open and read to EOF
on the child process, then try to read past the end of the buffer in the
parent process.  The immediate problem seems to be that the filehandle
in the parent process still sees the EOF condition that the read in the
child has produced.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




reply via email to

[Prev in Thread] Current Thread [Next in Thread]