Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001141 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Enhancement Request 2017-05-18 09:18 2020-04-23 13:55
Reporter joerg View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Jörg Schilling
Organization
User Reference
Section Headers
Page Number 409
Line Number 13896
Interp Status ---
Final Accepted Text See Note: 0004157
Summary 0001141: Add WCOREDUMP(stat) to sys/wait.h
Description Given that the interface for waitid() includes CLD_DUMPED as required
value for siginfo.code, we should require to define WCOREDUMP(stat)
for waitpid() as well.
Desired Action After line 13896 add the following:

    WCOREDUMP(stat) If the value of WIFSIGNALED (stat) is
                           non-zero, this macro evaluates to a
                           non-zero value if a core image of the
                           terminated child was created.
Tags issue8
Attached Files

- Relationships
related to 0001215Applied XSI shading on text about abnormal termination with actions 
related to 0001416Applied Misuses of "may" on the getrlimit() page 

-  Notes
(0003697)
kre (reporter)
2017-05-18 13:15

I agree, though the wording should probably include a ref to XBD 3.117
(0004152)
eblake (manager)
2018-10-18 16:21

The Linux kernel does not reliably set WCOREDUMP if a core dump could have been produced but was not - there are a number of factors (ulimit, file permissions, whether the kernel is configured to dump to file vs. to pipeline, ...):
https://bugzilla.redhat.com/show_bug.cgi?id=1607938 [^]
https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg05842.html [^]
(0004153)
kre (reporter)
2018-10-19 03:16
edited on: 2018-10-19 13:11

Re note 4152: Huh?

First, WCOREDUMP is a macro, it cannot be "set" - it is a test for an
event ... but I will take the note as meaning "WCOREDUMP() does not reliably
return true if ..."

And wrt that, if it ever returns true when a core dump was not produced,
it (ie: linux) is broken. It doesn't matter why it wasn't produced, that's
an exercise for the recipient to determine -- or always has been ... just
as nothing actually says what the name of the core file will be, including
where it will be produced, all of that is system dependent (ie: unspecified).

As Joerg's proposed wording says "if a core image of the terminated child
**was created**" - this is how it has always been, and is also consistent
with the definition of CLD_DUMPED (page 337, line 11415 "and created a core
file".

We do not need dynamic (per exit) information to inform the application
"the signal that caused the child to exit normally makes core files", as
that's (at least) a system wide constant (an interface to provide that
mapping might be useful, though its lack has never seemed to bother anyone).

All that said, the Desired Action is not really correct (the intent is
right, the execution faulty...) At line 13896, to be consistent with
the others, all that should be added is the name, WCOREDUMP, and a
very brief description of what the macro does. The details, including
mention of the parameter, should be added on page 2227 (exactly where
is not so important, but probably somewhere just after line 70961)
and that is where Joerg's proposed wording should appear (this is in the
description of the wait() interface).

(0004154)
kre (reporter)
2018-10-19 03:26

This next bit is just an editorial change, and if you all believe
a new issus is needed for this, rather than just including it with
this one, I will open one, but given that to fix this issue the
description of wait() (page 2227) needs to be edited anyway, it seems
reasonable to throw in this minor additional change (unrelated to core
dumps...)

At lines 70963 - 70964 it currently says of WIFSTOPPED(stat_val):

        Evaluates to a non-zero value if status was returned for a
        child process that is currently stopped.

"currently stopped" is wrong, it is not even clear what that means
("currently" when? When the macro is evaluated? Surely not.
When the status was returned from wait() - perhaps, but that's not
really correct either, I don't think. This should be reworded more
like that for WIFCONTINUED() (its counterpart) which says:

        Evaluates to a non-zero value if status was returned for a
        child process that has continued from a job control stop.

which is past tense, and more vague about just when the event happened,
and does not claim to be giving any information about the current state
of the child process.
(0004155)
geoffclare (manager)
2018-10-19 08:43

Re Note: 0004154 the wording for WIFSTOPPED should be like WIFSIGNALED, i.e.:
Evaluates to a non-zero value if status was returned for a child process that stopped due to the receipt of a signal that was not caught (see [xref to <signal.h>]).


For WIFCONTINUED I would suggest removing the word "has".
(0004156)
joerg (reporter)
2018-10-19 09:47
edited on: 2018-10-19 10:56

Re: Note: 0004153

This is a good point! We already describe the modern waitid() interface to
either set the exit reason to

CLD_KILLED where a signal caused the death

or to

CLD_DUMPED where a signal caused the death and a core file has been
created.

Since Linux is not POSIX compliant as it does not implement a correctly
working waitid(), Linux would first need to implement a working waitid()
and then it could easily implement an emulation for the historic waitpid()
or wait() functions on top of the modern of waitid(). If that was done,
Linux did behave as other platforms with respect to the WCOREDUMP()
macro.

(0004157)
nick (manager)
2018-11-01 16:09
edited on: 2018-11-08 16:43

On Page 52, lines 1614-1615, change:

<h2>Core File</h2>
A file of unspecified format that may be generated when a process terminates
abnormally.


to


<h2>Core Image</h2>
An unspecified object of unspecified format that may be generated when
a process terminates abnormally.


On page 337 lines 11414 - 11415, change


CLD_KILLED Child has terminated abnormally and did not create a core file.
CLD_DUMPED Child has terminated abnormally and created a core file.

to

CLD_KILLED Child has terminated abnormally with no additional actions.
CLD_DUMPED Child has terminated abnormally and additional actions may have
                been taken.


On page 378 line 12904 change "core file" to "core image".

On page 450 lines 15518 - 15520, change:

While the example using _SC_VERSION in the APPLICATION USAGE section does
not provide the greatest degree of imaginable utility to the application
developer or user, it is arguably better than a core file or some other
equally obscure result.

to

While the example using _SC_VERSION in the APPLICATION USAGE section does
not provide the greatest degree of imaginable utility to the application
developer or user, it is arguably better than the production of a core
image or some other equally obscure result.


On page 491, line 16999, change "core file" to "core image".

On page 1086, lines 36861-36863, change:


RLIMIT_CORE
This is the maximum size of a core file, in bytes,
that may be created by a process. A limit of 0 shall prevent
the creation of a core file. If this limit is exceeded,
the writing of a core file shall terminate at this size.

to

RLIMIT_CORE
This is the maximum size of a file containing a core image,
in bytes, that may be created by a process. A limit of 0 shall
prevent the creation of such a file. If this limit is exceeded,
the writing of a file containing a core image shall terminate
at this size. NOTE the production of such a file may be one of the
implementation defined actions for abnormal termination.


On page 2233 line 71220, change:

Implementations that support core file creation or other
implementation-defined actions ...

to

Implementations that support implementation-defined actions, such as the
creation of a file containing a core image, ...


Page 2615 line 85034 change

Clean up core files every weekday morning at 3:15 am:

to

Remove files named core every weekday morning at 3:15 am:


Page 2793 line 91788 change "core" to "file containing a core image"

Page 2988 line 9299-9301, change

The results from SIGQUIT are partially unspecified because, on systems
that create core files upon receipt of SIGQUIT, the core
from make would conflict with a core file from the command that
was running when the SIGQUIT arrived.

to

The results from SIGQUIT are partially unspecified because, on systems
that create a file named core upon receipt of SIGQUIT, the core file
from make would conflict with a core file from the command that
was running when the SIGQUIT arrived.


On page 3125 line 104585, change

SZ (l) The size in blocks of the core image of the process.

to

SZ (l) The size in pages of the total memory requirements of the process, including text, data, stack, mapped memory and other resources.


On Page 359, before line 12257, insert
WCOREDUMP

On page 409 line 13896 section <sys/wait.h>, add before WEXITSTATUS:

WCOREDUMP True if WIFSIGNALED is true and creation of a core image was attempted.
NOTE: The use of the word "attempted"
here means that the process terminated abnormally
with actions (see "SIG_DFL" in [xref to 2.4.3 Signal Actions]).
A core image might or might not have been
produced. Some implementations do not set this bit if
a core image was not produced, but this is not a requirement.


On page 409 line 13901 section <sys/wait.h>, change the WIFSTOPPED text from:

True if child is currently stopped.


to:

True if child stopped due to uncaught signal.


On page 2227 line 70963 section wait(), change the WIFSTOPPED text from:

Evaluates to a non-zero value if status was returned for a child process that is currently stopped.


to:

Evaluates to a non-zero value if status was returned for a child process that stopped due to the receipt of a signal that was not caught (see [xref to <signal.h>]).


On page 2227 line 70958 section wait(), add:
WCOREDUMP(stat_val)
If the value of WIFSIGNALED(stat_val) is non-zero, this macro evaluates to a non-zero value if the creation of a core image of the terminated child was attempted.



- Issue History
Date Modified Username Field Change
2017-05-18 09:18 joerg New Issue
2017-05-18 09:18 joerg Name => Jörg Schilling
2017-05-18 09:18 joerg Section => Headers
2017-05-18 09:18 joerg Page Number => 409
2017-05-18 09:18 joerg Line Number => 13896
2017-05-18 13:15 kre Note Added: 0003697
2018-10-18 16:21 eblake Note Added: 0004152
2018-10-19 03:16 kre Note Added: 0004153
2018-10-19 03:26 kre Note Added: 0004154
2018-10-19 08:43 geoffclare Note Added: 0004155
2018-10-19 09:47 joerg Note Added: 0004156
2018-10-19 09:47 joerg Note Edited: 0004156
2018-10-19 09:48 joerg Note Edited: 0004156
2018-10-19 09:49 joerg Note Edited: 0004156
2018-10-19 10:56 joerg Note Edited: 0004156
2018-10-19 13:11 kre Note Edited: 0004153
2018-11-01 16:09 nick Note Added: 0004157
2018-11-01 16:11 nick Note Edited: 0004157
2018-11-01 16:12 nick Note Edited: 0004157
2018-11-01 16:13 nick Interp Status => ---
2018-11-01 16:13 nick Final Accepted Text => See Note: 0004157
2018-11-01 16:13 nick Status New => Resolved
2018-11-01 16:13 nick Resolution Open => Accepted As Marked
2018-11-01 16:13 nick Tag Attached: issue8
2018-11-01 16:21 eblake Note Edited: 0004157
2018-11-08 16:43 nick Note Edited: 0004157
2018-11-09 16:42 geoffclare Relationship added related to 0001215
2020-04-23 13:55 geoffclare Status Resolved => Applied
2020-11-03 10:46 geoffclare Relationship added related to 0001416


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker