cygwin gfortran segfaulting on valid write statements

cygwin gfortran segfaulting on valid write statements

[worsafe]

I'm getting segfaults in valid write statements Using current cygwin 
gfortran (--version reports 9.3.0). This is with old code that runs on 
current debian stable and was running on cygwin a few years ago. I have 
been unable to construct a simple example for a bug report.

I would like to try downgrading the gfortran version, but see 6 
different versions of gcc-fortran and 11 versions of libgfortran in the 
cygwin repository. Can someone recommend a combination?

Re: cygwin gfortran segfaulting on valid write statements

[Marco Atzeri]

Am 17.04.2020 um 20:42 schrieb worsafe@bellsouth.net:
> I'm getting segfaults in valid write statements Using current cygwin 
> gfortran (--version reports 9.3.0). This is with old code that runs on 
> current debian stable and was running on cygwin a few years ago. I have 
> been unable to construct a simple example for a bug report.
> 
> I would like to try downgrading the gfortran version, but see 6 
> different versions of gcc-fortran and 11 versions of libgfortran in the 
> cygwin repository. Can someone recommend a combination?
> 


9.3.0-1   libgfortran5
9.2.0-3   libgfortran5
9.2.0-2   libgfortran5
9.2.0-1   libgfortran5
8.3.0-1   libgfortran5
7.4.0-1   libgfortran4


in what type of statement have you the segfault ?

Regards
Marco

Re: cygwin gfortran segfaulting on valid write statements

[Charles Russell]

On 4/17/2020 2:39 PM, Marco Atzeri via Cygwin wrote:

> in what type of statement have you the segfault ?


I recently tried building and running some old fortran code using what I 
think is the current version of cygwin gfortran (--version reports 
9.3.0) and was surprised to get a run-time error message saying that a 
format statement was missing a left parenthesis. There was no format 
error in that line (the same code ran previously on cygwin, and runs now 
on debian stable). Furthermore I would not expect to see a syntax error 
message at run time. I got around the problem by switching from cygwin 
to a debian virtual machine, but then went back for another look at 
cygwin, using different (old, tested) code. Again I hit a segfault, this 
time with no explicit message, but stepping through gdb tracked the 
error to a write statement. Copying the offending write statement into a 
simple example failed to reproduce the error.

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 12:42, worsafe@bellsouth.net wrote:
> I'm getting segfaults in valid write statements Using current cygwin gfortran
> (--version reports 9.3.0). This is with old code that runs on current debian
> stable and was running on cygwin a few years ago. I have been unable to
> construct a simple example for a bug report.
> 
> I would like to try downgrading the gfortran version, but see 6 different
> versions of gcc-fortran and 11 versions of libgfortran in the cygwin repository.
> Can someone recommend a combination?

Try these in order from recent to less:

gcc-fortran	9.3.0-1 9.2.0-3 9.2.0-2 9.2.0-1 8.3.0-1 7.4.0-1
libgfortran5	9.3.0-1 9.2.0-3 9.2.0-2 9.2.0-1 8.3.0-1
libgfortran4						7.4.0-1

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 12:42, worsafe@bellsouth.net wrote:
> I'm getting segfaults in valid write statements Using current cygwin gfortran
> (--version reports 9.3.0). This is with old code that runs on current debian
> stable and was running on cygwin a few years ago. I have been unable to
> construct a simple example for a bug report.

Try running under strace:

	$ strace -o prog.strace prog -options... args...

or gdb:

	$ gdb prog
	(gdb) run -options... args...
	SEGV diagnostics
	(gdb) bt
	(gdb) q

and attach or paste all output.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: cygwin gfortran segfaulting on valid write statements

[Charles Russell]

On 4/17/2020 2:46 PM, Brian Inglis wrote:

> Try running under strace:
> 
> 	$ strace -o prog.strace prog -options... args...
> 
> or gdb:
> 
> 	$ gdb prog
> 	(gdb) run -options... args...
> 	SEGV diagnostics
> 	(gdb) bt
> 	(gdb) q
> 
> and attach or paste all output.

The following is the case where I got an error message. Not actually a 
segfault. (Sorry, I'm not a programmer.) The executable, gdb, and strace 
all produce the same output:
-----------
At line 889 of file cgcrez.f (unit = 6, file = 'stdout')
Fortran runtime error: Missing initial left parenthesis in format

^

Error termination. Backtrace:
#0  0xffffffffffffffff in ???
#1  0xffffffffffffffff in ???
#2  0xffffffffffffffff in ???
#3  0xffffffffffffffff in ???
#4  0xffffffffffffffff in ???
#5  0xffffffffffffffff in ???
#6  0xffffffffffffffff in ???
#7  0xffffffffffffffff in ???
#8  0xffffffffffffffff in ???
#9  0xffffffffffffffff in ???
#10  0xffffffffffffffff in ???
#11  0xffffffffffffffff in ???
#12  0xffffffffffffffff in ???
#13  0xffffffffffffffff in ???
--------------
Here is the indicated line, using list mode in vim to show that there 
are no unexpected nonprinting characters:

  887           write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$
  888      &       iter, reldf,reldb,$
  889      &       gnorms, x1min, -cosag, beta(1),beta(np)$
  890 $

This code compiled and ran on cygwin in the past, and checks out now in 
debian stable.

In my other case, which I may or may not be able to find again, the 
program failed with no explicit error message like the one above. 
Stepping through with gdb showed that it was also crashing in a valid 
write statement.

Re: cygwin gfortran segfaulting on valid write statements

[Brian Inglis]

On 2020-04-17 17:33, Charles Russell wrote:
> On 4/17/2020 2:46 PM, Brian Inglis wrote:
> 
>> Try running under strace:
>>
>>     $ strace -o prog.strace prog -options... args...
>>
>> or gdb:
>>
>>     $ gdb prog
>>     (gdb) run -options... args...
>>     SEGV diagnostics
>>     (gdb) bt
>>     (gdb) q
>>
>> and attach or paste all output.
> 
> The following is the case where I got an error message. Not actually a segfault.
> (Sorry, I'm not a programmer.) The executable, gdb, and strace all produce the
> same output:
> -----------
> At line 889 of file cgcrez.f (unit = 6, file = 'stdout')
> Fortran runtime error: Missing initial left parenthesis in format
> ^

> Here is the indicated line, using list mode in vim to show that there are no
> unexpected nonprinting characters:
> 
>  887           write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$
>  888      &       iter, reldf,reldb,$
>  889      &       gnorms, x1min, -cosag, beta(1),beta(np)$
>  890 $
> 
> This code compiled and ran on cygwin in the past, and checks out now in debian
> stable.
> 
> In my other case, which I may or may not be able to find again, the program
> failed with no explicit error message like the one above. Stepping through with
> gdb showed that it was also crashing in a valid write statement.

Do you perhaps need an extra pair of parentheses to repeat the formatted output,
perhaps from the second specifier, as you have 5 variable format specifiers and
8 variables?
Showing a bit more context with all variable declarations would help, and you
can use cat -A (== -vET) to show non-printing characters e.g.

$ egrep -nw 'iter|reldf|reldb|gnorms|x1min|cosag|beta|write' cgcrez.f | cat -A

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: gfortran 9.3 write format error (was: segfaulting on valid write statements)

[Brian Inglis]

On 2020-04-17 23:16, Charles Russell wrote:
> On 4/17/2020 8:01 PM, Brian Inglis wrote:
>> On 2020-04-17 17:33, Charles Russell wrote:
>>> At line 889 of file cgcrez.f (unit = 6, file = 'stdout')
>>> Fortran runtime error: Missing initial left parenthesis in format
>>> ^
>>> Here is the indicated line, using list mode in vim to show that there are no
>>> unexpected nonprinting characters:
>>>  887           write(6,'(i6,1p3e9.2,x,e9.2,x,0pf6.3,x,1p2e10.2,''@'')')$
>>>  888      &       iter, reldf,reldb,$
>>>  889      &       gnorms, x1min, -cosag, beta(1),beta(np)$
>>>  890 $
>>> This code compiled and ran on cygwin in the past, and checks out now in debian
>>> stable.
>>> In my other case, which I may or may not be able to find again, the program
>>> failed with no explicit error message like the one above. Stepping through with
>>> gdb showed that it was also crashing in a valid write statement.

>> Do you perhaps need an extra pair of parentheses to repeat the formatted output,
>> perhaps from the second specifier, as you have 5 variable format specifiers and
>> 8 variables?

> Looks OK to me, and works on debian.
> 
> (i6,        iter
> 1p3e9.2,    reldf, reldb, gnorms       
> x,       
> e9.2,        x1min
> x,
> 0pf6.3,        -cosag
> x,
> 1p2e10.2,       beta(1), beta(np)
> '' @'')

>> Showing a bit more context with all variable declarations would help, and you
>> can use cat -A (== -vET) to show non-printing characters e.g.
>>
>> $ egrep -nw 'iter|reldf|reldb|gnorms|x1min|cosag|beta|write' cgcrez.f | cat -A
> 
> This yields 200 lines of output and I don't see how it helps, but I'll send you
> the output if you wish. Regarding declarations, this is fortran 77 code with g77
> extensions using implicit double precision (a-h,o-z), i.e. traditional fortran
> type conventions but double precision. The code was originally written using g77
> and gfortran on cygwin, passes ftnchek, and runs fine on current debian stable.
> Hard to see how this can be anything but a problem with the current cygwin
> compiler or its installation. My program uses a half dozen static libraries
> built within the past year (after switching from 32 bit cygwin on windows 7 to
> 64 bit cygwin on windows 10). I suppose there might be some mismatch with these
> libraries, though I did check to make sure that none of my 32 bit libraries
> slipped in. If I have to downgrade the compiler version I'll presumably need to
> rebuild all my libraries yet again.

Unfortunately without a Simple Test Case it is hard to reproduce the errors and
most of us are not (recent) ForTran programmers, and available ForTran docs seem
less than rigorous in specifying formatted I/O format requirements, with
gfortran providing not even hints.

However, one thing we have become used to is more warnings about questionable
practices in every release, more warning conditions disrupting compilation such
that they are treated as errors, and stricter checking of all aspects of programs.

What are your build command lines for the programs giving errors, and what
compiler version are you using on Debian - 8.3?

You can get more details about the configured and assumed defaults by running on
Cygwin and Debian:

	$ touch null.f
	$ gfortran -v   null.f |& tee gfortran-v.log
	$ gfortran -### null.f |& tee gfortran-###.log

You may not have problems if you are building with default -std=gnu or explicit
-std=legacy, but other options may give errors with obsolescent extensions, as
your formats may be considered, although as far as I can see, there is no
gfortran documentation which would support that.

As I did not recognize 1p[23]e... as a repeated format, it is possible that
gfortran now requires you to specify that in a more standards compliant manner,
except perhaps if you compile with -std=legacy (and the runtime supports that in
formatted I/O format strings), otherwise you may want to try restating your
formats in a more standard manner e.g.

	'(i6,3(1pe9.2),x,e9.2,x,0pf6.3,x,2(1pe10.2),''@'')'

which may or may not solve your problem.

I am shocked that gfortran does not appear to me to support any options for
checking string formats at compile time (contrasted with the dozen or so options
for C format string checking), controlling formatting conventions used at
runtime, or really any rigorous treatment of what format options, grammar, and
specifiers are supported at compile time, or in strings at runtime.

You may want to check out the (scant) available documentation at:

	https://gcc.gnu.org/fortran/
	https://gcc.gnu.org/wiki/GFortran

the mailing list archives at:

	https://gcc.gnu.org/pipermail/fortran/
	https://gcc.gnu.org/legacy-ml/fortran/

especially why gfortran is incompatible with g77:

	https://gcc.gnu.org/legacy-ml/fortran/2007-01/msg00619.html

If changing your formats eliminates the errors, I suggest you report a format
compatibility bug against gfortran on the gcc bugzilla, and request they provide
some user documentation for supported compiler and runtime formats, other than
the doxygen internals docs for gfortran and libgfortran.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: gfortran 9.3 write format error

[Eliot Moss]

 > As I did not recognize 1p[23]e... as a repeated format, it is possible that
 > gfortran now requires you to specify that in a more standards compliant manner,
 > except perhaps if you compile with -std=legacy (and the runtime supports that in
 > formatted I/O format strings), otherwise you may want to try restating your
 > formats in a more standard manner e.g.
 >
 > 	'(i6,3(1pe9.2),x,e9.2,x,0pf6.3,x,2(1pe10.2),''@'')'
 >
 > which may or may not solve your problem.

Or maybe write 1p,3e9.2 since the scale factor thing is actually a separate
format element (I believe, from cruising what general Fortran docs I found
around the Internet).

Best - Eliot

Re: gfortran 9.3 write format error

[Charles Russell]

On 4/18/2020 11:23 AM, Brian Inglis wrote:
  what compiler version are you using on Debian

$ gfortran --version
GNU Fortran (Debian 8.3.0-6) 8.3.0

When support ended for g77 I feared for my collection of old fortran 
code, but it all worked fine under gfortran after a few trivial changes 
that I made years ago. (BLOCK DATA had to be rewritten, but I had used 
that only once.) The gfortran developers must intend to keep viable all 
that netlib code that has been widely used and thoroughly debugged. No 
problems with the above gfortran version, which is newer than the most 
recent one for Cygwin. So I doubt that the error message comes from 
intentional compiler changes.

Like you, I can't understand why a syntax error should appear at run 
time.  gfortran is good at finding syntax errors at compile time.

I'm still using fortran 77 because it meets my needs, I know where the 
bugs hide, and that is the language of most netlib code and of all my 
old tools. gfortran handles it well.

Re: gfortran 9.3 write format error

[worsafe]

Error in my last message - the current debian gfortran (8.3.0) is in 
fact older than the current cygwin fortran (9.3.0).  So I'll try 
downgrading to 8.3.0 in cygwin.

Re: gfortran 9.3 write format error

[worsafe]

There was an error in my last message In fact, the current cygwin 
gfortran is 9.3.0, the current debian compiler is 8.3.0. I'll have to 
reflect upon that.

Re: gfortran 9.3 write format error

[Charles Russell]

Problem solved (probably).

When setting out to downgrade gfortran, I found that there was a slight 
upgrade available - 9.3.0.1 to 9.3.0.2. I upgraded, ran "make clean" and 
"make test".  This time it ran to completion with no error message.

Seems unlikely this minor upgrade fixed a major problem.  More likely, 
reinstalling gfortran was what fixed it.

I was having similar problems with other programs, not just this one, 
and time will tell whether upgrading fixed everything.