View Issue Details

IDProjectCategoryView StatusLast Update
00008711003.1(2013)/Issue7+TC1System Interfacespublic2020-04-16 15:20
Reportershware_systems Assigned To 
PrioritynormalSeverityCommentTypeOmission
Status ClosedResolutionDuplicate 
NameMark Ziegast
OrganizationSHware Systems Development
User Reference
Sectionsem_getvalue, sem_post, sem_*wait
Page Numbermany
Line Number58951, 59170, others
Interp Status---
Final Accepted TextSee 0000871:0002400.
Summary0000871: Missing potential error code, EOVERFLOW
DescriptionIn looking over reports 869, 870 I noticed that the sem_post() interface requires an int value be incremented, but does not provide an application a means of detecting arithmetic overflow of that value, when the SIGFPE signal is blocked, in a way distinguishable from an attempt to use an uninitialized sem_t record, currently reported by the EINVAL error code. While this may be a corner case usually encountered only when an application has an infinite loop containing a sem_post() call, not detecting it may cause threads to spuriously unblock, by increment to 0, or sem_getvalue to return an invalid waiting processes count.

Whether this should be a sticky case, requiring the semaphore be reinitialized before other access attempts succeed, or what other side effects should be required behavior I feel needs discussion, so Desired Action sparse.
Desired ActionAdd to the Error Codes section of the related interfaces:

[EOVERFLOW] The semaphore count was incremented past INT_MAX, invalidating the semaphore usage.

Additional language about usage caveats, historical practice, signal interactions, etc.
TagsNo tags attached.

Relationships

duplicate of 0000315 Closedajosey 1003.1(2004)/Issue 6 sem_post maximum number of semaphores 

Activities

dalias

2014-08-27 00:35

reporter   bugnote:0002365

I would strongly prefer that, if sem_post fails, there should be no change to the semaphore value. Declaring the semaphore object unusable is no better, from an application perspective, than the current situation where the result is simply not defined; there will rarely be any reasonable way an application could recover from a no-longer-usable synchronization object once it has started using it for synchronization.

Since pthread_mutex_lock uses EAGAIN for the equivalent condition on recursive mutexes, there is some question as to which error code should be preferred. I mildly prefer EAGAIN since EOVERFLOW seems to imply that an overflow already occured, rather than that the operation cannot be performed because an overflow would occur. If there is disagreement on the above semantics though (whether the semaphore is usable after overflow), perhaps both could be specified, with EOVERFLOW meaning that the semaphore has overflowed and is no longer usable, and EAGAIN meaning that the post cannot be performed because it would overflow (and the semaphore is still in a usable state). This would leave both choices open to implementations while letting applications know which behavior they got.

Don Cragun

2014-10-02 17:00

manager   bugnote:0002400

Last edited: 2014-10-02 17:41

Although we agree that EAGAIN or ERANGE (as used in semop()) might be better choices for this error, at least one implementation already uses EOVERFLOW for this condition. We didn't find a compelling reason to change existing practice.

Add to the sem_post() ERRORS section after P1837, L59190:
[EOVERFLOW] The semaphore value would exceed {SEM_VALUE_MAX}.


shware_systems

2014-10-02 17:10

reporter   bugnote:0002401

As SEM_VALUE_MAX now referenced, suggest at Line 59201, Change:
    XBD Section 4.11 (on page 110), <semaphore.h>

to:
    XBD Section 4.11 (on page 110), <semaphore.h>, <limits.h>

Don Cragun

2014-10-02 17:31

manager   bugnote:0002402

The final accepted text has been updated to fix the issue noted in 0000871:0002401.

Don Cragun

2014-10-02 17:40

manager   bugnote:0002403

Last edited: 2014-10-02 17:42

I reacted too soon. Please disregard 0000871:0002402. The SEE ALSO list doesn't need to be updated for SEM_UNDO_MAX because this value by being enclosed in braces is clearly a limit that would be found in <limits.h> and an application does not need to know the value of that limit to use sen_post(). The change to the SEE ALSO section has been removed from the final accepted text.

geoffclare

2020-04-02 09:14

manager   bugnote:0004810

This is a duplicate of bug 0000315. I believe 315 should stand and this one should be closed as a dup of it, since 315 is an approved interpretation and it adds EOVERFLOW as a "shall fail" whereas this bug (incorrectly in my view) adds it as a "may fail".

geoffclare

2020-04-16 15:20

manager   bugnote:0004825

This was discussed in the April 16th, 2020 teleconference and the meeting decided that bug 0000315 was correct in adding EOVERFLOW to the "shall fail" section and this bug was incorrect in adding it to "may fail". Therefore the consensus is that this should be closed as a duplicate of 315.

Issue History

Date Modified Username Field Change
2014-08-26 16:51 shware_systems New Issue
2014-08-26 16:51 shware_systems Name => Mark Ziegast
2014-08-26 16:51 shware_systems Organization => SHware Systems Development
2014-08-26 16:51 shware_systems Section => sem_getvalue, sem_post, sem_*wait
2014-08-26 16:51 shware_systems Page Number => many
2014-08-26 16:51 shware_systems Line Number => 58951, 59170, others
2014-08-27 00:35 dalias Note Added: 0002365
2014-10-02 17:00 Don Cragun Interp Status => ---
2014-10-02 17:00 Don Cragun Note Added: 0002400
2014-10-02 17:00 Don Cragun Status New => Resolved
2014-10-02 17:00 Don Cragun Resolution Open => Accepted As Marked
2014-10-02 17:01 Don Cragun Final Accepted Text => See 0000871:0002400.
2014-10-02 17:02 Don Cragun Tag Attached: issue8
2014-10-02 17:02 Don Cragun Note Edited: 0002400
2014-10-02 17:06 Don Cragun Note Edited: 0002400
2014-10-02 17:07 Don Cragun Note Edited: 0002400
2014-10-02 17:10 shware_systems Note Added: 0002401
2014-10-02 17:30 Don Cragun Note Edited: 0002400
2014-10-02 17:31 Don Cragun Note Added: 0002402
2014-10-02 17:40 Don Cragun Note Added: 0002403
2014-10-02 17:41 Don Cragun Note Edited: 0002400
2014-10-02 17:42 Don Cragun Note Edited: 0002403
2020-04-02 09:14 geoffclare Note Added: 0004810
2020-04-02 09:14 geoffclare Relationship added duplicate of 0000315
2020-04-16 15:20 geoffclare Note Added: 0004825
2020-04-16 15:20 geoffclare Status Resolved => Closed
2020-04-16 15:20 geoffclare Resolution Accepted As Marked => Duplicate
2020-04-16 15:22 geoffclare Tag Detached: issue8