Do not use Calling the signal()
function in a multithreaded program . This is undefined behavior in C11 (Section 7.14.1.1, paragraph 7). Furthermore, in POSIX, sending an uncaught signal in order to kill a thread causes the signal to kill the entire process, not just the individual thread.
This rule is a specific instance of SIG02-C. Avoid using signals to implement normal functionality.
. (See undefined behavior 135.)
Noncompliant Code Example
This code raises a signal within a child thread. This is meant to terminate the program, but results in undefined behavior.noncompliant code example invokes the signal()
function from a multithreaded program:
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *data) { /* ... */ if (thread_should_exit#include <signal.h> #include <stddef.h> #include <threads.h> volatile sig_atomic_t flag = 0; void handler(int signum) { flag = raise( SIGTERM); // Undefined! } /* ... */ } int main(void1; } /* Runs until user sends SIGUSR1 */ int func(void *data) { int result; thrd_t thread; int result; if ((result = thrd_create(&tid, func, NULL)) != thrd_successwhile (!flag) { /* Handle Error... */ } return 0; } |
Compliant Solution
This code terminates the child thread rather than raising a signal. This has the same effect as the noncompliant code example, but is well-defined in C11.
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *data int main(void) { /* ... */ if (thread_should_exit) { thrd_exit(0signal(SIGUSR1, handler); //* OK } /* ... */ } int main(void) { int result; Undefined behavior */ thrd_t threadtid; int result; if ((resultthrd_success != thrd_create(&tid, func, NULL)) != thrd_success) { /* Handle Errorerror */ } /* ... */ return 0; } |
Noncompliant Code Example (POSIX)
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 uses an object of type atomic_bool
to indicate when the child thread should terminate its loop:This code uses the pthread_kill()
function to send a SIGTERM
signal to the created thread. The thread receives the signal, and the entire process is terminated.
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *foo) { /* Execution of thread */ } int main(void) { int result; pthread_t thread; if ((result = pthread_create(&thread, NULL, func, 0)) != 0#include <stdatomic.h> #include <stdbool.h> #include <stddef.h> #include <threads.h> atomic_bool flag = ATOMIC_VAR_INIT(false); int func(void *data) { /* Handle Error */ } if ((result = pthread_kill(thread, SIGTERM)) != 0while (!flag) { /* Handle... Error */ } /* This point is not reached because the process terminates in pthread_kill() */ return 0; } |
Compliant Solution (POSIX)
This compliant code uses instead the pthread_cancel()
function to terminate the thread. The thread continues to run until it reaches a cancellation point. See The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition [Open Group 2004] for lists of functions that are required and allowed to be cancellation points. If the cancellation type is set to asynchronous, the thread is terminated immediately. However, POSIX requires only the pthread_cancel()
, pthread_setcancelstate()
, and pthread_setcanceltype()
functions to be async-cancel safe. An application that calls other POSIX functions with asynchronous cancellation enabled is nonconforming. Consequently, we recommend disallowing asynchronous cancellation, as explained by POS47-C. Do not use threads that can be canceled asynchronously.
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *foo) { /* Execution of thread */ } int main(void) { intthrd_t resulttid; pthread_t thread; if ((resultthrd_success != pthreadthrd_create(&threadtid, NULL, func, 0)) != 0NULL)) { /* Handle Errorerror */ } if ((result = pthread_cancel(thread)) != 0) {/* ... */ /* Set /*flag Handlewhen Errordone */ } flag /* Continue executing */= true; return 0; } |
Exceptions
CON37-C-EX1: Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule [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 |
Bibliography
[OpenBSD] signal()
Man Page
[ISO/IEC 9899:2011]
...
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" |
...