我正在使用ptrace与PTRACE_O_TRACEFORK | PTRACE_O_TRACEEXEC | PTRACE_O_TRACEVFORK | PTRACE_O_TRACEVFORKDONE | PTRACE_O_TRACECLONE跟踪一个进程,它是孩子(和孩子的孩子).该机制很像strace,但目的略有不同,因为我只是追踪被读取或修改的文件.
我的代码(以C编写)在x86-64架构上的Debian wheezy和Debian jessie上工作正常(在i386上也较少测试).当我尝试在Ubuntu Precise x86-64虚拟机(使用3.2.0内核)上编译和运行时,我遇到麻烦.
在精确的机器上,有时我发现在vfork调用发生后,我不会立即收到PTRACE_EVENT_VFORK,而是开始接收事件(一些SIGSTOP事件和一些系统调用),而不会得到PTRACE_EVENT_VFORK事件.在执行系统调用时,我没有看到任何可疑的内容,而且行为是不可预测的.
我不知道如何尝试将其减少到最小的错误情况,我真的不知道可能会出现什么问题,从未见过这种失踪事件的行为.可以想见,差异不在于内核,而是我正在跟踪的构建工具(它是python gcc的组合).
有什么建议么？
解决方法
您使用PTRACE_SETOPTIONS注册的各种事件会生成与正常ptrace事件不同的消息.但正常事件仍然生成.一个正常的事件是新的分叉过程开始停止,并且必须从跟踪器继续.
这意味着如果您使用PTRACE_O_TRACEFORK(或VFORK)注册了事件,则在fork之后,waitpid将为同一进程触发两次.
一个将是一个状态是：
WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == SIGSTOP)
另一个将与：
WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == 0) &&
((status >> 16) == PTRACE_EVENT_FORK) /* or VFORK */
内核似乎没有任何保证,他们将以什么顺序到达.我发现我的系统接近50/50.
为了处理这个我的代码看起来像这样：
static void
proc_register(struct magic *pwi,pid_t pid,bool fork) {
/*
* When a new process starts two things happen:
* - We get a wait with STOPPED,SIGTRAP,PTRACE_EVENT_{CLONE,FORK,VFORK}
* - We get a wait with STOPPED,SIGSTOP
*
* Those can come in any order,so to get the proc in the right
* state this function should be called twice on every new proc. If
* it's called with fork first,we set the state to NEW_FORKED,if
* it's called with STOP first,we set NEW_STOPPED. Then when the
* other call comes,we set the state to TRACED and continue the
* process.
*/
if ((p = find_proc(pwi,pid)) == NULL) {
p = calloc(1,sizeof(*p));
p->pid = pid;
TAILQ_INSERT_TAIL(&pwi->procs,p,list);
if (fork) {
p->state = NEW_FORKED;
} else {
p->state = NEW_STOPPED;
}
} else {
assert((fork && p->state == NEW_STOPPED) || (!fork && p->state == NEW_FORKED));
p->state = TRACED;
int flags = PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT|PTRACE_O_TRACEFORK|PTRACE_O_TRACEVFORK;
if (ptrace(PTRACE_SETOPTIONS,pid,NULL,flags))
err(1,"ptrace(SETOPTIONS,%d)",pid);
if (ptrace(PTRACE_CONT,signal) == -1)
err(1,"ptrace(CONT,%d,signal);
}
}
[...]
pid = waitpid(-1,&status,__WALL);
if (WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == SIGSTOP)) {
proc_register(magic,false);
} else if (WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == 0) && ((status >> 16) == PTRACE_EVENT_FORK)) {
proc_register(magic,true);
} else {
/* ... */
}
完成此工作的关键是不发送PTRACE_CONT,直到我们收到这两个事件.当弄清楚这是如何工作的时候,我发送PTRACE_CONT太多,内核乐意接受他们,有时甚至导致我的进程在PTRACE_EVENT_FORK到达之前很久.这使得调试相当困难.
注：我没有找到关于这个的任何文件或任何说明这是应该的方式.我刚刚发现,这使事情能够像今天一样发挥作用.因人而异.
