DynamoRIO / DynamoRIO/dynamorio

sigpending does not work

Open
#2,563 1 comment 0 reactions 0 assignees View on GitHub
OpSys-UNIX
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 18h
Merged PRs (30d)
30

Description

Test program:
```
#include
#include
#include

int main()
{
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGUSR1);
sigprocmask(SIG_BLOCK, &set, NULL);
sigpending(&set);
printf("%d\n", sigismember(&set, SIGUSR1));
kill(getpid(), SIGUSR1);
sigpending(&set);
printf("%d\n", sigismember(&set, SIGUSR1));
return 0;
}
```

I get "0 1" natively and "0 0" under DynamoRIO.

The test program blocks SIGUSR1 with sigprocmask, checks with sigpending whether SIGUSR1 is pending, sends SIGUSR1 to itself, then checks sigpending again.

It seems that DynamoRIO does not really block the signal when the app calls rt_sigprocmask, so it accepts the SIGUSR1 when it arrives, though it does not deliver it to the app, so SIGUSR1 is found not to be pending by the second call to rt_sigpending.

This particular test could be fixed by emulating rt_sigpending to take account of signals queued up by the runtime but there are other difficulties with DynamoRIO accepting a signal that ought to be blocked. For example, when the app is running natively the kernel will deliver a signal to the thread that does not have it blocked. If DynamoRIO accepts the signal in the wrong thread then redirecting it later would be really complicated, even if you could somehow work out whether the signal was sent to that particular thread or to the thread group. So why does DynamoRIO queue up signals in the runtime rather than block them when the app blocks them?

I think DynamoRIO already blocks all signals except SIGV and USR2 between accepting a signal and delivering that signal to the app, which is good. So if DynamoRIO could also block signals when the app blocks them perhaps there would be no need to queue up signals in the runtime.

(This may have been discussed before but I can't find any record of a discussion. I would guess that leaving signals unblocked somehow improved tool support. If so, it would be good to record a summary of the costs and benefits of this approach.)

Contributor guide

Open the contributing guide

Research direction

Start with the standalone C reproducer in the issue and run it natively and under DynamoRIO to compare sigprocmask, kill, and sigpending behavior. Trace the runtime's signal blocking, queuing, and delivery paths to determine why blocked signals are accepted. Done means either correcting the semantics or documenting the design trade-offs and required behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.