2 ms·
The ideal approach would be if it turned the original process memory into "copy on write", and created a paused exact copy of that process. This would give a co
by avodonosov 7y ago
The ideal approach would be if it turned the original process memory into "copy on write", and created a paused exact copy of that process. This would give a consistent, immutable, snapshot of the target process memory, without freezing for the duration of actual memory copying.
One could then take a core dump, java heap dump, or similar, of the paused copy process.
I'm curious, why does the tool try to copy the original process memory into the memory of the tool itself, risking a collision? Is it impossible to create a third process - an exact copy of the original process?
- Liskni_si 7y agoThe FAQ says: > all while leaving no ptrace and sending no signal If this is a design goal, I'm afraid it is indeed impossible to take a snapshot of the original process. As far as I know (I researched the status quo 2 years ago when I needed copy-on-write for VM cloning/forking), the only way to make a snapshot of a process' address space is to invoke the clone (fork) system call. If you need to take a snapshot of another process, then you need ptrace. But you're absolutely right that the unfork functionality itself can be implemented more robustly by doing this ptrace/fork trick.