ptrace wait loop: signal forwarding, FORK/VFORK events, group-stop suppression

[widgetii]

While investigating an empty trace from libsns_jxf22.so on hi3518ev200, three real bugs in the wait loop turned up that are worth fixing independently of jxf22's specific issue.

Bugs fixed

1. Signal forwarding

The loop ended every iteration with ptrace(PTRACE_SYSCALL, pid, 1, NULL). The fourth arg is the signal to inject when resuming the tracee, and NULL meant "drop the signal entirely". So if a child stopped on a real signal (anything other than SIGTRAP — SIGCHLD, SIGRT*, SIGUSR*, etc.), ipctool swallowed it instead of forwarding it. The HiSilicon SDK uses realtime signals heavily; dropping them under trace can deadlock a streamer.

Now: if the stop signal is SIGTRAP, the resume signal stays at 0; if it's a genuine signal-delivery stop, the original signal gets re-injected when the tracee resumes.

2. Group-stop / post-clone init-stop suppression

Subtle interaction with #1: the kernel SIGSTOPs a newly cloned tracee as part of TRACECLONE bookkeeping. With my naive forwarding fix above, we'd forward SIGSTOP back to the new clone — keeping it permanently stopped and producing the exact "empty trace" symptom on multi-threaded streamers.

Now: SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU are recognised as group-stops / job-control / clone-init stops and explicitly suppressed (signal=0 on resume). Other real signals still forward.

3. PTRACE_EVENT_FORK / PTRACE_EVENT_VFORK ignored

#152 added the matching PTRACE_O_TRACEFORK/VFORK options but the wait loop only matched PTRACE_EVENT_CLONE. So a forked child fired PTRACE_EVENT_FORK in its parent (ignored), then on its first syscall stop the lookup against pids returned NULL and we hit the "BAD lookup" branch which break'd out of the wait loop — killing the whole trace. The exit handler also broke on missing-pid lookup. Both cases now continue gracefully.

Investigation tooling

tools/sns_init_probe.c — dlopen+dlsym wrapper to load a libsns_*.so directly and call its sensor init function. Lets future researchers exercise sensor I/O paths in isolation from the streamer.

What this PR does NOT fix

The hi3518ev200 + jxf22 specific empty-trace remains. Diagnostic data:

strace -f /usr/bin/majestic  : 79 writes captured, all on TID 1671 (main thread)
strace    /usr/bin/majestic  : 0  writes (clone'd worker activity invisible)
ipctool trace ...            : 0  writes despite TRACECLONE | TRACEFORK
                                 and the three fixes in this PR

Same kernel, same camera, same libsns_jxf22.so, same ptrace primitive — strace gets the writes, ipctool doesn't. The bug must be in ipctool's specific event handling on this combo. Without on-target step-debug it's hard to narrow further; reserving for a follow-up.

Test plan

• SC2315E + Majestic regression: 100/100/100% diff against widgetii/smart_sc2315e unchanged
• CI test-extraction-pipeline passes
• No regression on cv300+IMX291 / av200+IMX385

🤖 Generated with Claude Code