missing output

[Tobias Burnus]

Damian,

what you might want to try is to lengthen the output – as mentioned:
"One difference  could be that the string variable used for internal write
is longer and the tailing spaces make a difference."

Thus, if you add, e.g., 100 spaces at the end, does it help?

What I find very puzzling is that only the second output doesn't produce
any output while the first one and subsequent ones do.

Another option which comes to my mind is that some control character 
causes problems – such as a carriage return ('\r') + text which 
overrides the output – or a bunch of backspace characters (^H alias 
\08). This only works if the are smuggled before the line-break 
character. Using escape sequences, one could even move up and left, such 
that one can overwrite the text even after the line break ('\n').

If you don't view the output on the terminal (which interprets the 
output) but using an editor or 'less' (w/o '-r' or '-R') you should see 
the control characters if they are there.

In any case, it is an odd problem.

Cheers,

Tobias

On 12/11/19 10:52 AM, Damian Rouson wrote:
> Thanks, Tobias.   Because you mentioned MPICH buffering, I decided to 
> try moving to the latest stable release of MPICH.  And I also tried 
> setting GFORTRAN_UNBUFFERED_ALL=1. No luck.
>
> D
>
> On Wed, Dec 11, 2019 at 1:22 AM Tobias Burnus <tobias@codesourcery.com 
> <mailto:tobias@codesourcery.com>> wrote:
>
>     Hi Damian,
>
>     I have no idea – and, in particular, I don't see why it should make a
>     difference to do an internal write to a string and then have a single
>     string for list-directed I/O vs. having two strings and two
>     integers for
>     a list-directed I/O. – Maybe someone else can spot something peculiar
>     about this regarding stdout/output_unit, but I cannot. One difference
>     could be that the string variable used for internal write is
>     longer and
>     the tailing spaces make a difference.
>
>     Regarding libgfortran: it uses POSIX's 'write', which is unbuffered
>     according to the spec. But by default gfortran does internally
>     buffers
>     I/O. However, you can use the environment variable
>     GFORTRAN_UNBUFFERED_PRECONNECTED (value: y/Y/1 or n/N/0) to force
>     unbuffered STDOUT/STDERR – and GFORTRAN_UNBUFFERED_ALL to use
>     unbuffered
>     I/O for all files.
>
>     Of course, the parallelization library (likely: Open MPI or MPICH)
>     has
>     to capture the STDOUT/STDERR text and pass it on. Also here something
>     can go wrong.
>
>     For instance, MPICH has: "MPIEXEC_STDOUTBUF — Sets the buffering mode
>     for standard output. Valid values are NONE (no buffering), LINE
>     (buffering by lines), and BLOCK (buffering by blocks of
>     characters; the
>     size of the block is implementation defined). The default is NONE."
>
>     Cheers,
>
>     Tobias
>
>
>     On 12/11/19 7:31 AM, Damian Rouson wrote:
>     > Gfortran developers,
>     >
>     > I am contributing to an open-source project with about 90K lines
>     of Fortran
>     > code and am curious if anyone can offer some perspective on a
>     particularly
>     > perplexing heisenbug.  It would be challenging to produce a
>     reduced case so
>     > I haven't submitted a bug report.  I get the following behavior with
>     > gfortran 8.3.1, 9.2.0, and the trunk.
>     >
>     > At the following line is a WRITE to OUTPUT_UNIT:
>     >
>     >
>     https://github.com/radiasoft/zgoubi/blob/single-image-writes/utilities/data-partition-impl.f90#L92
>     >
>     > immediately followed by a FLUSH and then a currently commented
>     conditional
>     > STOPÂ  that halts execution on the second pass through the
>     encompassing
>     > subroutine.  Without the stop statement, the second pass through the
>     > subroutine produces no output even though previous and
>     subsequent passes
>     > produce output.  Any thoughts on what might cause this?
>     >
>     > Zaak Beekman (cc'd) has mentioned seeing such behavior in which 
>     gfortran
>     > seems to optimize away certain output.  He has found that
>     putting the
>     > output in a character variable (presumably by internal file I/O)
>     first and
>     > then writing it fixes the problem.  That didn't work in this
>     case and I see
>     > this problem even with -O0 so I assume it's not related to
>     optimization.
>     >
>     > I don't expect that anyone will attempt to build and run this
>     code, but if
>     > anyone so desires, please let me know so that I can explain how
>     to find and
>     > execute the relevant test case.
>     >
>     > Damian
>