Signal call from within signal handler
Nonpersistent signal handler calling signal()
in Windows system causes race condition
Description
This defect occurs when you call the function signal()
from a signal
handler on Windows® platforms.
The defect is detected only if you specify a Visual Studio compiler. See Compiler
(-compiler)
.
Risk
The function signal()
associates a signal with a signal handler
function. On platforms such as Windows, which removes this association after receiving the signal, you might call the
function signal()
again within the signal handler to
re-establish the association.
However, this attempt to make a signal handler persistent is prone to race conditions.
On Windows platforms, from the time the signal handler begins execution to when the
signal
function is called again, it is the default signal handling,
SIG_DFL
, that is active. If a second signal is received within this
time window, you see the default signal handling and not the custom signal handler, but you
might expect otherwise.
Fix
Do not call signal()
from a signal handler on Windows platforms.
Examples
Result Information
Group: Programming |
Language: C | C++ |
Default: On for handwritten code, off for generated code |
Command-Line Syntax:
SIG_HANDLER_CALLING_SIGNAL
|
Impact: Medium |
Version History
Introduced in R2017b
See Also
Find defects (-checkers)
| Function called from signal handler not asynchronous-safe
| Return from computational exception signal handler
| Shared data access within signal handler
Topics
- Interpret Bug Finder Results in Polyspace Desktop User Interface
- Interpret Bug Finder Results in Polyspace Access Web Interface (Polyspace Access)
- Address Results in Polyspace User Interface Through Bug Fixes or Justifications
- Address Results in Polyspace Access Through Bug Fixes or Justifications (Polyspace Access)