Now that I'm reading through the code, you say in the preamble:
> In the original version, the utility would unconditionally freeze the program with PTRACE_ATTACH, but this probably causes more problems than it solves.
But reading ptrace man, it seems to me that PTRACE_ATTACH will immediately send SIGSTOP. And if you wanted to avoid, you'd have to use PTRACE_SEIZE (since Linux 3.4).
So I don't understand what's the "unconditional remark"; it seems to me that memfetch will stop the process (because the `attach_to_process()` is always called), unless it's instructed to wait for fault signal (because there it sends PTRACE_CONT and watches for the fault signal delivery).
Right, the original version would always issue PTRACE_ATTACH, which always stopped the traced program, then performed the dump and released the program with PTRACE_DETACH.
The current version doesn't do that, instead dumping memory while the process is running *unless* you specify -s (in which case, it goes through PTRACE_ATTACH + PTRACE_CONT because it needs to monitor the process and intercept faults).
The downside are possible race conditions without -s; the upside is sidestepping the whole ptrace(...) mess, which reduces the odds of clashing with debuggers / sandboxes / anti-debug measures.
Of course, Plan 9 from Bell Labs went further with the "everything is a file" concept so you can actually make network connections just by reading and writing files: https://9p.io/sys/doc/net/net.html
Actually, a question...
Now that I'm reading through the code, you say in the preamble:
> In the original version, the utility would unconditionally freeze the program with PTRACE_ATTACH, but this probably causes more problems than it solves.
But reading ptrace man, it seems to me that PTRACE_ATTACH will immediately send SIGSTOP. And if you wanted to avoid, you'd have to use PTRACE_SEIZE (since Linux 3.4).
So I don't understand what's the "unconditional remark"; it seems to me that memfetch will stop the process (because the `attach_to_process()` is always called), unless it's instructed to wait for fault signal (because there it sends PTRACE_CONT and watches for the fault signal delivery).
What am I missing?
Right, the original version would always issue PTRACE_ATTACH, which always stopped the traced program, then performed the dump and released the program with PTRACE_DETACH.
The current version doesn't do that, instead dumping memory while the process is running *unless* you specify -s (in which case, it goes through PTRACE_ATTACH + PTRACE_CONT because it needs to monitor the process and intercept faults).
The downside are possible race conditions without -s; the upside is sidestepping the whole ptrace(...) mess, which reduces the odds of clashing with debuggers / sandboxes / anti-debug measures.
Omg, I missed the `if (!wait_sig) return;` in `attach_to_process()`.
Yeah, now it makes sense. :-)
`s/threds/threads/` (L107)
`s/errror:/error:/` (L64)
sorry for being a pest; have nothing better to "contribute".
Small typo on line 231 of `memfetch.c` - https://gist.github.com/avranju/4b919a0ac8f66569a592ec01a2fb2eb6.
Thanks!
Of course, Plan 9 from Bell Labs went further with the "everything is a file" concept so you can actually make network connections just by reading and writing files: https://9p.io/sys/doc/net/net.html