Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument
From: robert.corbett on 14 May 2010 22:31
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.

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?

Robert Corbett
From: steve on 14 May 2010 23:02
On May 14, 7:31 pm, 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.
>
> 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.
>

Depending on the shell a user can set the core dump size
to whatever value you want.

laptop:kargl[216] limit
coredumpsize unlimited

To disable core dumps

laptop:kargl[217] limit coredumpsize 0
laptop:kargl[218] limit
coredumpsize 0 kbytes

laptop:kargl[226] limit coredumpsize 10M
laptop:kargl[227] limit
coredumpsize 10240 kbytes

One could also use atexit() to install a custom routine
and call exit() with a nonzero status.

--
steve
From: Richard Maine on 14 May 2010 23:36
<robert.corbett(a)oracle.com> wrote:

> 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.
....
> 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?

I don't see why the size of a core file has anything in particular to do
with end-of-file (or other i/o conditions). It seems to me that this is
a much more general issue unrelated to the i/o conditions. If the user
doesn't want core files because of their size or for any other reason, I
can see that. What I don't see is singling out the i/o conditions for
special attention. Sounds to me like a user focusing on what happened to
him on a particular day instead of looking at a larger and more
consistent picture. Is this same user going to soon turn around and ask
for core files to not be produced for the next particular kind of error
he happens to run into? Much better to show him how to avoid core files
in general than to hack things one at a time for each class of error
that he hits.

In addition to setting the core size limit as you mentioned, it isn't
exactly complicated or obscure for the Fortran user to check for
end-of-file conditions and handle them as he likes. Other kinds of
errors that can cause core files aren't always so easy to avoid.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: robert.corbett on 15 May 2010 06:03
On May 14, 8:36 pm, nos...(a)see.signature (Richard Maine) wrote:
> <robert.corb...(a)oracle.com> wrote:
> > 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.
> ...
> > 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?
>
> I don't see why the size of a core file has anything in particular to do
> with end-of-file (or other i/o conditions). It seems to me that this is
> a much more general issue unrelated to the i/o conditions. If the user
> doesn't want core files because of their size or for any other reason, I
> can see that. What I don't see is singling out the i/o conditions for
> special attention. Sounds to me like a user focusing on what happened to
> him on a particular day instead of looking at a larger and more
> consistent picture. Is this same user going to soon turn around and ask
> for core files to not be produced for the next particular kind of error
> he happens to run into? Much better to show him how to avoid core files
> in general than to hack things one at a time for each class of error
> that he hits.
>
> In addition to setting the core size limit as you mentioned, it isn't
> exactly complicated or obscure for the Fortran user to check for
> end-of-file conditions and handle them as he likes. Other kinds of
> errors that can cause core files aren't always so easy to avoid.

The user did not say why he thought end-of-file conditions should be
treated differently from i/o error conditions or errors. I can think
of
a possible reason. Many years ago, it was common for people to write
programs that looped until a READ statement reached the end of the
file
it was reading. At that time, the END= and IOSTAT= specifiers were
not
part of standard Fortran. Someone from that era might not consider an
end-of-file condition to be an error and therefore not think that
detecting an end-of-file condition calls for production of a core
file.

Bob Corbett
From: robin on 15 May 2010 11:30
<robert.corbett(a)oracle.com> wrote in message news:536222b7-35c5-4294-acec-88df347ad6f5(a)v29g2000prb.googlegroups.com...
| 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.

Natually.
Suggest using the "END=" option on the READ.

| He made the point that on
| modern machines core files are often gigabytes long and take
| some minutes to write.
|
| 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.

Better to trap the end-of-file and to write a nice message;
Then execution can continue at some useful place.

| 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?

No.
Better to trap the condition(s) and write a useful message,
then continue execution.

Programs that just die are not useful.


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