TODO: Check memory allocation and freeing in kernel functions that manage signals #40

New Issue

apio · 2023-08-07T20:04:55Z

apio commented

2023-08-07 20:04:55 +00:00

If a thread has a signal pending which is has its disposition set to SIG_DFL and the default is to terminate the process, Thread::process_pending_signals() never returns (instead calling kernel_exit(), which then calls kernel_yield(), which completely leaves the current execution context).

Thus, anything on the stack will not get its destructor called, which could result in a memory leak. Maybe instead of checking Thread::will_invoke_signal_handler() a Thread::will_ignore_signal() function should be checked instead? Thus, SIG_DFL terminating signals will also short-circuit and exit the calling function (calling all destructors) before Thread::process_pending_signals() is called in a controlled environment.

If a thread has a signal pending which is has its disposition set to SIG_DFL and the default is to terminate the process, Thread::process_pending_signals() never returns (instead calling kernel_exit(), which then calls kernel_yield(), which completely leaves the current execution context). Thus, anything on the stack will not get its destructor called, which could result in a memory leak. Maybe instead of checking Thread::will_invoke_signal_handler() a Thread::will_ignore_signal() function should be checked instead? Thus, SIG_DFL terminating signals will also short-circuit and exit the calling function (calling all destructors) before Thread::process_pending_signals() is called in a controlled environment.

apio referenced this issue from a commit

2023-08-08 08:44:58 +00:00

kernel: Interrupt syscalls before exiting because of a signal

apio closed this issue

2023-08-08 08:44:58 +00:00

Sign in to join this conversation.