Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000871 [1003.1(2013)/Issue7+TC1] System Interfaces Comment Omission 2014-08-26 16:51 2020-04-16 15:20
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Duplicate  
Status Closed  
Name Mark Ziegast
Organization SHware Systems Development
User Reference
Section sem_getvalue, sem_post, sem_*wait
Page Number many
Line Number 58951, 59170, others
Interp Status ---
Final Accepted Text See Note: 0002400.
Summary 0000871: Missing potential error code, EOVERFLOW
Description In 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 Action Add 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.
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0000315Appliedajosey 1003.1(2004)/Issue 6 sem_post maximum number of semaphores 

-  Notes
(0002365)
dalias (reporter)
2014-08-27 00:35

 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.
(0002400)
Don Cragun (manager)
2014-10-02 17:00
edited on: 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}.
(0002401)
shware_systems (reporter)
2014-10-02 17:10

 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>
(0002402)
Don Cragun (manager)
2014-10-02 17:31

 The final accepted text has been updated to fix the issue noted in Note: 0002401.
(0002403)
Don Cragun (manager)
2014-10-02 17:40
edited on: 2014-10-02 17:42

 I reacted too soon. Please disregard Note: 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.
(0004810)
geoffclare (manager)
2020-04-02 09:14

 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".
(0004825)
geoffclare (manager)
2020-04-16 15:20

 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 Note: 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

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