Special case SIGINT

[s1341]

Without this, SIGINTs get swallowed. Not sure why.

[ranweiler]

Thanks for the PR, @s1341.

Do you have a small repro case that exhibits the original bug? How did you test this change, and in what system configurations/versions?

[s1341]

I don't... I guess I could work one up. What I did was kill(SIGINT) and then ptracer.wait(), expecting to get a fresh tracee and a siginfo with the correct signal. This wasn't working correctly before.

[ranweiler]

@s1341 no worries, I can put together a test. My main question is more standard "bug report" stuff: repro steps (now answered), observed OS/target/version, etc.

[s1341]

OS was android 11 aarch64. Target was a random app, but this is reproducible even on a stupid while true { println("here\n"); } executable.

[ranweiler]

@s1341, sorry for the holdup. I wanted to repro this bug before taking the change, but I'm unable to. I tried both x86-64 and aarch64 Linux, which makes me think it is Android-specific. To accept this change, I'd probably want to make it Android-conditional, which will be a first (for the internal event loop), and require building some testing infra on my side.

For the sake of easier tracking, could you please open an issue for what you're seeing? Also, I've hardly done any Android work, so I'll probably ask you for tips on the easiest way to set up an emulator environment that matches yours.

FYI, I tried to repro by using the basic example's binary and running it like:

./basic /usr/bin/sleep 30

Then, in another shell session, I ran:

kill -INT $(pgrep sleep)

And the output I get from the tracer is:

pid = 2247, pc = ffffa82a40c0: SyscallExit
pid = 2247, pc = ffffa81c2fe8: SignalDelivery { signal: SIGINT }
pid = 2247, pc = ffffa81c2fe8: Signaling { signal: SIGINT, core_dumped: false }

Which is what I'd expect. This is with the latest main branch.