DETATCH,pid,NULL,NULL)在死pid上被调用?
我正在尝试捕获所有正在运行的进程的命令行参数。 其中一些进程的命令行超过了/ proc / $ {pid} / cmdline的4096个字符限制,因此读取该procfs文件不符合我的要求。 我感兴趣的进程可能是暂时的,所以我需要能够在我意识到它们的pid时立即从/ proc / $ {pid} / mem中的堆栈读取它们的命令行参数。 这需要在我的C代码中附加ptrace。
while (pid >= 0){
intPtraceReturnValue = ptrace(PTRACE_ATTACH,pid,NULL,NULL);
if(intPtraceReturnValue != -1){
wait(&intStatus);
readFromProcMem(pid); // function that handles /proc/${pid}/mem reading
intPtraceReturnValue = ptrace(PTRACE_CONT,pid,NULL,NULL);
wait(&intStatus);
intPtraceReturnValue = ptrace(PTRACE_DETATCH,pid,NULL,NULL);
printFoundCommandLineArgs(); // prints results.
}
pid = getNextPid(); // function that interrogates /proc for the next running pid.
}
有时PTRACE_ATTACH调用返回-1。 这通常发生在调用管道时,并且我可以接受在此情况下调用ptrace时,命令行参数会丢失到历史记录中。 但是,在其他情况下,ptrace附加成功,但我无法分离,因为在等待内核互斥体被PTRACE_CONT调用释放时,该过程完成。 也就是说,如果通过使用PTRACE_CONT的调用将intStatus设置为0,那么使用PTRACE_DETATCH的调用返回-1。 在运行几分钟后,我看不到与pid关联的内存。 有时我访问/ proc的列表似乎被拒绝。 在其他情况下,我只是得到空的结果。 我怀疑有一个ptrace附件表没有得到足够的清除,因为ptrace是在死pid上用PTRACE_DETACH调用的。 是这样吗? 如果是这样,我怎样才能手动清除悬挂附件? 如果没有,那么可能会有什么妨碍我访问/ proc? 我已经证实,当ptrace不参与时,程序的其他汇总部分单独工作。 我知道这是对ptrace的一种非正统的使用; 任何想法将不胜感激
你有多个问题,我会在你的代码中用评论指出它们:
while (pid >= 0){
intPtraceReturnValue = ptrace(PTRACE_ATTACH,pid,NULL,NULL);
// here you should call ptrace(PTRACE_INTERRUPT, pid, NULL, NULL) to stop the tracee
if(intPtraceReturnValue != -1){
wait(&intStatus);
readFromProcMem(pid); // function that handles /proc/${pid}/mem reading
// the PTRACE_CONT and wait are unnecessary
// intPtraceReturnValue = ptrace(PTRACE_CONT,pid,NULL,NULL);
// wait(&intStatus);
// the PTRACE_DETACH is enough to trigger the process to continue running
intPtraceReturnValue = ptrace(PTRACE_DETATCH,pid,NULL,NULL);
printFoundCommandLineArgs(); // prints results.
}
pid = getNextPid(); // function that interrogates /proc for the next running pid.
}
从你的问题来看,问题并不清楚,但是我非常肯定,如果你应用上述改变,你可能会得到更好的结果。
链接地址: http://www.djcxy.com/p/66381.html上一篇: DETATCH,pid,NULL,NULL) is called on a dead pid?
下一篇: Modifying global variables with ptrace programmatically