Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument
From: Louis Krupp on 15 May 2010 15:41
On 5/15/2010 4:03 AM, robert.corbett(a)oracle.com wrote:
> 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.

Would it be possible to add an environment variable that would force an
end-of-file condition to raise SIGTERM instead of SIGABRT?

Louis
From: Colin Watters on 15 May 2010 16:35


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

IMO the "default" behaviour ought to be kind to the novice user, because an
experienced user can be expected to know how to change the default settings
to achieve the behaviour s/he prefers. So what is the "kindest" thing to
do?

IMO that is to produce a core file of modest size, so it would be useful
for the typical size of program the novice might be developing, but small
enough to ensure no risk of disk space trauma. So I think the default core
size limit should be "modest", say 100KB.

Richard's point is also well taken, why single out end-of-file? do it for
all unhandled errors.

--
Qolin

Email: my qname at domain dot com
Domain: qomputing


From: Gary L. Scott on 15 May 2010 19:01
On 5/15/2010 2:41 PM, Louis Krupp wrote:
> On 5/15/2010 4:03 AM, robert.corbett(a)oracle.com wrote:
>> 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.
>
> Would it be possible to add an environment variable that would force an
> end-of-file condition to raise SIGTERM instead of SIGABRT?
>
> Louis
Core dump should never be the default, only a user selectable option.
Termination (depending) with a nice RT message should be the default.
From: Gordon Sande on 15 May 2010 21:53
On 2010-05-15 20:01:14 -0300, "Gary L. Scott" <garylscott(a)sbcglobal.net> said:

> On 5/15/2010 2:41 PM, Louis Krupp wrote:
>> On 5/15/2010 4:03 AM, robert.corbett(a)oracle.com wrote:
>>> 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.
>>
>> Would it be possible to add an environment variable that would force an
>> end-of-file condition to raise SIGTERM instead of SIGABRT?
>>
>> Louis
> Core dump should never be the default, only a user selectable option.
> Termination (depending) with a nice RT message should be the default.

Anyone capable of dealing with a coredump file will be quite capable of setting
options to get one. Others are more likely to by mystified as to what
they are and
have trouble getting rid of them. A plausible text message giving the
termination
reason is more likely to be of use.

A long time ago I used a system that provided a nicely formatted post mortem
of the user program which gave the values of all the variables up the call
list at the time of an errant termination. The system was ALCOR Algol 60 for
IBM 7090. It was a static dump based on a symbol table. The various interactive
debuggers I have seen recently provide a few lines that were in the full post
mortem dump. I would find it easier to scan the post morten dump listing than
to use the various debuggers I have used. Their only merit is that they provide
a one step facility which quickly becomes useless once a program is of
any size.
Folks seem to praise them but it sure sounds like saying they are better than
nothing (which is true) but they seem far short of the utility of the ALCOR
post mortem dumps.

I believe there was an equivalent post mortem facility for one of the debugging
PL/Is (Cornell PL/C?) but I have not been aware of any others. Is there any
nice tool for dealing with a Unix coredump that is directed at other than
system programmers - i.e. for end users who are doing some of their own
programming? Any time I have used Unix I ended up with the classical use
of adding print/write rather than using a debugger. No one ever recommended
anything else to me. Did I miss something useful?



From: Colin Watters on 16 May 2010 11:13


"Gordon Sande" <Gordon.Sande(a)gmail.com> wrote in message
news:2010051522534875249-GordonSande(a)gmailcom...

> ...
>
>
> A long time ago I used a system that provided a nicely formatted post
> mortem
> of the user program which gave the values of all the variables up the
> call
> list at the time of an errant termination. The system was ALCOR Algol 60
> for
> IBM 7090. It was a static dump based on a symbol table. The various
> interactive
> debuggers I have seen recently provide a few lines that were in the full
> post
> mortem dump. I would find it easier to scan the post morten dump listing
> than
> to use the various debuggers I have used. Their only merit is that they
> provide
> a one step facility which quickly becomes useless once a program is of
> any size.
> Folks seem to praise them but it sure sounds like saying they are better
> than
> nothing (which is true) but they seem far short of the utility of the
> ALCOR
> post mortem dumps.
>

I too used a post mortem dump utility, PMD, which was a property of CDC's
compilers & run-time systems. That too was a Long Time Ago (but maybe not
quite as long ago as Gordon ...;-) ).

PMD was great for batch run programs. But IMO interactive debuggers are far
superior because (a) you can debug a program before it crashes, and in the
absense of a crash (even non-crashing programs can benefit greatly from
debugging); (b) you can follow the path of execution of the program, and
therefore understand how it got to someplace it never ought to be; (c) if a
crash occurs the debugger is activated and you can examine whatever
variables seem interesting. But of course you need to be running the
program interactively.

The "one step" facility is just the tip of the interactive debugger
iceberg: apart from step in vs step over (follow execution into a call, or
step to the stateent after the call) you can: set breakpoints to give the
debugger control at interesting code lines; follow the call stack up and
down and interrogate variables anywhere in the stack of active routines;
set conditional breakpoints that get triggered if a variable is changed or
referenced; and a whole lot more.

The code I debug is definately not small, at circa 400K lines. I develop on
Windows with IVF, running under Mr Gates' Visual Studio. I know there are
alternatives that do approximately the same under Linux but I have never
used them. IMO a programmer's productivity is greatly enhanced once s/he
has access to a such a debugger and has taken the time to become familiar
with it.

I would NEVER go back to debugging by planting print statements in the
code.

--
Qolin

Email: my qname at domain dot com
Domain: qomputing


First  |  Prev  |  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