Chapter 3: Facing issue with PTRACE_CONT

[sistavk]

Hi All,

The tracee isn't printing anything after PTRACE_CONT and waitpid but it prints after providing PTRACE_CONT again as shown in the below code

if(is_prefix(command, "continue")){
  resume(pid);
  wait_on_signal(pid);
  resume(pid);
}

Did any one face similar issue ?

Platform: Ubuntu 22.04.3
GCC: 11.4.0

[ultrakapy]

I faced a similar issue on Ubuntu 20.04.6. I suspect the issue here is that the code as written in the book was likely tested on WSL1 (or a similar system), where signals from child processes are often broadcast differently. On native Linux ptrace, intercepted signals are not automatically forwarded to the tracee. The tracer must explicitly reinject or forward them whenever it makes sense to do so.

On native Linux, when a tracee is stopped (e.g., via SIGTRAP from a breakpoint), the tracer is notified via waitpid. However, the signal is not consumed. It remains "pending."

When you call PTRACE_CONT with a signal argument of 0 (which resume likely does), the kernel assumes you want to suppress that signal. The tracee stays in a stopped state or misses the event required to trigger its output, which is why it only seems to "wake up" after you provide the second PTRACE_CONT.

In the code provided:

1. First resume(pid): Sends PTRACE_CONT.
2. wait_on_signal(pid): The tracer waits, but the tracee is now paused by the signal it just hit.
3. Second resume(pid): This finally clears the state and allows the tracee to proceed.

To fix this on native Ubuntu (and other native Linux systems), you must capture the signal from waitpid using WSTOPSIG(status) and pass that signal back to the tracee.

Here's how I did that: https://github.com/ultrakapy/sdb/blob/ac2e241dd7947365f3f31d5a12b9954ba0cf7011/tools/sdb.cpp#L82C7-L93C8

The ptrace call in your resume logic should eventually look like this:

// Instead of always passing 0, pass the actual signal received
ptrace(PTRACE_CONT, pid, NULL, signal_to_forward);