pussuw commented on code in PR #8740:
URL: https://github.com/apache/nuttx/pull/8740#discussion_r1133048434
##########
sched/signal/sig_dispatch.c:
##########
@@ -373,11 +373,11 @@ int nxsig_tcbdispatch(FAR struct tcb_s *stcb, siginfo_t
*info)
#endif
{
#ifdef CONFIG_LIB_SYSCALL
- /* If the thread is in syscall, schedule the sigaction here */
+ /* If the thread is in syscall, queue the sigaction here */
- if ((stcb->flags & TCB_FLAG_SYSCALL) != 0)
+ if (masked == 0)
Review Comment:
>As, I mention before, it's seldom that user call sigwait/signal
action/signalfd at the same time.
I agree but what if there is a default sigaction, like SIGTERM. If the user
app for example is written like this:
```
int main(void)
{
while(true)
{
sleep(5);
}
return 0;
}
```
It will be in sleep() which means it is waiting for a signal. Then sending
`kill *pid*` will simply wake the task but not kill it. This works in flat mode
/ when system calls are not enabled as SIGTERM can never be masked, so the
`masked==0` branch is executed, and it adds the signal action to the pending
signal action queue. But when system calls are enabled the `masked == 1 ||
insyscal` branch is executed, and SIGTERM action is never executed :(
This is the issue I face, but I will fix it next week by making a new queue
for pended signal actions when the task is in system call. Using
nxsig_add_pendingsignal is not correct for this as it also adds a pending
signal which will abort any subsequent call to sigwait() and its friends.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
