Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel: Cannot send signal to self #4336

Closed
ADKaster opened this issue Dec 6, 2020 · 3 comments · Fixed by #4347
Closed

Kernel: Cannot send signal to self #4336

ADKaster opened this issue Dec 6, 2020 · 3 comments · Fixed by #4347
Labels
bug Something isn't working

Comments

@ADKaster
Copy link
Member

ADKaster commented Dec 6, 2020

Consider the following program:

send-signal-to-self.cpp

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

volatile sig_atomic_t saved_signal = -1;
volatile bool got_signal = false;

static void my_handler(int sig)
{
    saved_signal = sig;
    got_signal = true;
}

int main()
{
    if (SIG_ERR == signal(SIGUSR1, my_handler)) {
        perror("signal");
        return 1;
    }

    sleep(1);

    if (0 != kill(getpid(), SIGUSR1)) {
        perror("kill");
        return 2;
    }

    sleep(1);

    if (!got_signal) {
        fprintf(stderr, "Where's my signal, bro?\n");
        return 3;
    }

    printf("Got signal %d\n", saved_signal);

    return 0;
}

In serenity, this prints "Where's my signal, bro?"
signal-to-self

On Ubuntu 20.04, it prints, "Got signal 10".

andrew@DESKTOP-QQ5PM6D:~/testing$ g++ send-signal-to-self.cpp -o send-signal-to-self
andrew@DESKTOP-QQ5PM6D:~/testing$ ./send-signal-to-self 
Got signal 10
andrew@DESKTOP-QQ5PM6D:~/testing$ 
@ADKaster
Copy link
Member Author

ADKaster commented Dec 6, 2020

cc @tomuta perhaps? Not sure who's touched signal handling recently.

@ADKaster ADKaster changed the title Cannot send signal to self Kernel: Cannot send signal to self Dec 6, 2020
@tomuta
Copy link
Collaborator

tomuta commented Dec 6, 2020

I'll take a look this weekend I hope. Thanks for the sample code :)

@DrewStratford
Copy link
Contributor

Looks like this is happening because dispatch_one_pending_signal is only being called during Scheduler::context_switch; the thread probably won't cause a context_switch, so the signal won't be dispatched.

We could solve this by moving signal dispatching to the end of the interrupt handler, just before we re-enter userspace. This would have the added benefit of removing the need for send_urgent_signal_to_self, which was always a bit hackish.

tomuta added a commit to tomuta/serenity that referenced this issue Dec 7, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 8, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 8, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 8, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 9, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 11, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 11, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
tomuta added a commit to tomuta/serenity that referenced this issue Dec 12, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes SerenityOS#4336 and SerenityOS#4330
@linusg linusg added the bug Something isn't working label Dec 12, 2020
awesomekling pushed a commit that referenced this issue Dec 12, 2020
Fix some problems with join blocks where the joining thread block
condition was added twice, which lead to a crash when trying to
unblock that condition a second time.

Deferred block condition evaluation by File objects were also not
properly keeping the File object alive, which lead to some random
crashes and corruption problems.

Other problems were caused by the fact that the Queued state didn't
handle signals/interruptions consistently. To solve these issues we
remove this state entirely, along with Thread::wait_on and change
the WaitQueue into a BlockCondition instead.

Also, deliver signals even if there isn't going to be a context switch
to another thread.

Fixes #4336 and #4330
awesomekling added a commit that referenced this issue Jan 30, 2022
Signal dispatch is already taken care of elsewhere, so there appears to
be no need for the hack in enter_current().

This also allows us to remove the Thread::m_in_block flag, simplifying
thread blocking logic somewhat.

Verified with the original repro for #4336 which this was meant to fix.
LucasChollet pushed a commit to LucasChollet/serenity that referenced this issue Feb 3, 2022
Signal dispatch is already taken care of elsewhere, so there appears to
be no need for the hack in enter_current().

This also allows us to remove the Thread::m_in_block flag, simplifying
thread blocking logic somewhat.

Verified with the original repro for SerenityOS#4336 which this was meant to fix.
LucasChollet pushed a commit to LucasChollet/serenity that referenced this issue Feb 3, 2022
Signal dispatch is already taken care of elsewhere, so there appears to
be no need for the hack in enter_current().

This also allows us to remove the Thread::m_in_block flag, simplifying
thread blocking logic somewhat.

Verified with the original repro for SerenityOS#4336 which this was meant to fix.
supercomputer7 pushed a commit to supercomputer7/serenity that referenced this issue Feb 4, 2022
Signal dispatch is already taken care of elsewhere, so there appears to
be no need for the hack in enter_current().

This also allows us to remove the Thread::m_in_block flag, simplifying
thread blocking logic somewhat.

Verified with the original repro for SerenityOS#4336 which this was meant to fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants