Calling the signal()
function in a multithreaded program is undefined behavior, according to the C Standard. (See also undefined behavior 135 of Annex J.)This rule is a specific instance of SIG02-C. Avoid using signals to implement normal functionality.
Noncompliant Code Example
This noncompliant code sets a signal handler while also setting a child thread to do work, which results in undefined behavior.code example invokes the signal()
function from a multithreaded program:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <signal.h> #include <stddef.h> #include <threads.h> volatile sig_atomic_t flag = 0; void handler(int signum) { flag = 1; } /* Runs until user sends SIGUSR1 */ int func(void *data) { while (!flag) { /* ... */ } return 0; } int main(void) { signal(SIGUSR1, handler); /* Undefined! behavior */ thrd_t tid; if (thrd_success != thrd_create(&tid, func, NULL)) { /* Handle error */ } /* ... */ return 0; } |
NOTE: The SIGUSR1
signal value is not defined in the C Standard; consequently, this is not a C-compliant code example.
Compliant Solution
This compliant solution dispenses with the signal handler and uses an object of type atomic_flagbool
to indicate when the child thread should terminate its loop:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdatomic.h> #include <stdbool.h> #include <stddef.h> #include <threads.h> atomic_flagbool flag = ATOMIC_VAR_INIT(0false); int func(void *data) { while (!flag) { /* ... */ } return 0; } int main(void) { int result; thrd_t tid; if (thrd_success != thrd_create(&tid, func, NULL)) { /* Handle error */ } /* ... */ /* Set flag when done */ while (!atomic_flag_test_and_set(&flag)) = ; /* Continue attempts */true; return 0; } |
Exceptions
CON37-C-EX1: Platforms Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule . This exception would include POSIX, for example[IEEE Std 1003.1-2013].
Risk Assessment
Mixing signals and threads causes undefined behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
CON37-C | Low | Probable | Low | P6 | L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| stdlib-use-signal | Fully checked | ||||||
CodeSonar |
| BADFUNC.SIGNAL | Use of signal | ||||||
Coverity |
| MISRA C 2012 Rule 21.5 | Over-constraining | ||||||
Cppcheck Premium |
| premium-cert-con37-c | Fully implemented | ||||||
Helix QAC |
| C5021 C++5022 | |||||||
Klocwork |
| MISRA.STDLIB.SIGNAL | |||||||
LDRA tool suite |
| 44 S | Enhanced enforcement | ||||||
Parasoft C/C++test |
| CERT_C-CON37-a | The signal handling facilities of <signal.h> shall not be used | ||||||
PC-lint Plus |
| 586 | Fully supported | ||||||
Polyspace Bug Finder |
| CERT C: Rule CON37-C | Checks for signal call in multithreaded program (rule fully covered) | ||||||
RuleChecker |
| stdlib-use-signal | Fully checked |
Bibliography
[IEEE Std 1003.1-2013] | XSH 2.9.1, "Thread Safety" |
...