Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument
From: glen herrmannsfeldt on 18 May 2010 07:30
robert.corbett(a)oracle.com wrote:
> When Oracle Solaris Fortran terminates execution because of an
> end-of-file condition, it writes a message to standard error and then
> calls the C library routine abort. The C routine abort tries to close
> all open files and then raises SIGABRT. If there is no signal handler
> for SIGABRT, the OS will normally try to produce a core file.

> I recently received a request from a user asking that abort not be
> called for an end-of-file condition. He made the point that on
> modern machines core files are often gigabytes long and take
> some minutes to write.

Certainly I can imagine cases where one would want a core file
in the case of unexpected end-of-file. In Fortran 66, there was
no way for a program to detect and process the end of a file,
though IBM compilers added the END= option that later
became standard.

> If a user does not want a core file to be produced, he can set the
> limit on the size of a core file to zero. That has the effect of
> suppressing production of a core file for any exception.

I believe that is usual. Most systems that I knew default to
coredumpsize 0. One has to explicitly change that, such as in
the .cshrc file, to get an actual core file.

> I would like to know what others think of this request. Also,
> should abort be called for the end-of-record condition and
> i/o error conditions?

The only disadvantage that I could see is that one might want
to see a core file for another reason, and be surprised to
see one for these cases. Most of the time when I do generate
a core file, all I want to see is the traceback, so I can find
the actual cause.

The OS/360 compilers that I used many years ago would, for
some error conditions, give a traceback of the routine and
statement in that routine currently being executed.
(Also, the contents of four registers that might be useful.)
Often that was enough to track down the problem.

-- glen
From: Paul van Delst on 17 May 2010 19:05
robert.corbett(a)oracle.com wrote:
> When Oracle Solaris Fortran terminates execution because of an
> end-of-file condition, it writes a message to standard error and then
> calls the C library routine abort. The C routine abort tries to close
> all open files and then raises SIGABRT. If there is no signal handler
> for SIGABRT, the OS will normally try to produce a core file.
>
> I recently received a request from a user asking that abort not be
> called for an end-of-file condition. He made the point that on
> modern machines core files are often gigabytes long and take
> some minutes to write.

Richard Maine said it better (and more politely) than I would have: what do core files
(and their size/length-of-creation time) have to do with an EOF error condition?

> If a user does not want a core file to be produced, he can set the
> limit on the size of a core file to zero. That has the effect of
> suppressing production of a core file for any exception.
>
> I would like to know what others think of this request. Also, should
> abort be called for the end-of-record condition and i/o error
> conditions?

For i/o error conditions, that are not handled by the user's code, yes, I believe abort
should be called. I would want the code to stop with an error message.

For users "from that era" where an unhandled EOF might not be an error.... well, my (not
so useful) response would be to state that it's not "that era" any more. If an encountered
EOF is *not* an error condition, then the user code should handle it. The user writing (or
maintaining) the code has more information about the expected error conditions than the
compiler could ever have.

But regardless, isn't there a "--dusty-deck" switch to the Sun compiler that could be
setup to allow this behaviour?

This sort of request calls to mind the message that valgrind outputs when it encounters
too many errors: "Fix your code!"

:o)

cheers,

paulv
From: robert.corbett on 19 May 2010 02:39
On May 17, 4:05 pm, Paul van Delst <paul.vande...(a)noaa.gov> wrote:
> robert.corb...(a)oracle.com wrote:
> > When Oracle Solaris Fortran terminates execution because of an
> > end-of-file condition, it writes a message to standard error and then
> > calls the C library routine abort. The C routine abort tries to close
> > all open files and then raises SIGABRT. If there is no signal handler
> > for SIGABRT, the OS will normally try to produce a core file.
>
> > I recently received a request from a user asking that abort not be
> > called for an end-of-file condition. He made the point that on
> > modern machines core files are often gigabytes long and take
> > some minutes to write.
>
> Richard Maine said it better (and more politely) than I would have: what do core files
> (and their size/length-of-creation time) have to do with an EOF error condition?

An end-of-file condition is not an error condition. There is nothing
in the Fortran standards that suggests that it is an error to read an
endfile record. The standard does make continuing to read after an
endfile record has been read nonconforming, but that neither applies
to the case in question here, nor does it ensure that an error
condition will be detected. Therefore, a user could reasonably assert
that an end-of-file condition should not be treated as an error.

I assume that the user tolerated the run-time system generating a core
file as long as the core files were small and took little to generate.

Bob Corbett
First  |  Prev  | 
Pages: 1 2 3 4
Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument