DynamoRIO / DynamoRIO/dynamorio
sigpending does not work
- 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
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