Eric W. Biederman wrote: >"Richard F Weber" writes: > >>Ok, so as a rehash, the ptrace & open(),lseek() on /proc/*/mem should >>both work about the same. After a lot of struggling, I've gotten the >>ptrace to work right & spit out the data I want/need. However there is >>one small problem, SIGSTOP. >> >>ptrace() appears to set up the child process to do a SIGSTOP whenever >>any interrupt is received. Which is kind of a bad thing for what I'm >>looking to do. I guess I'm trying to write a non-intrusive debugger >>that can be used to view static variables stored in the heap of an >>application. >> >>On other OS's, this can be done just by popping open /proc/*/mem, and >>reading the data as needed, allowing the child process to continue >>processing away as if nothing is going on. I'm looking to do the same >>sort of task under Linux. >> >>Unfortunately, ptrace() probobally isn't going to allow me to do that. >>So my next question is does opening /proc/*/mem force the child process >>to stop on every interrupt (just like ptrace?) >> > > >The not stopping the child should be the major difference between >/proc/*/mem and ptrace. > See this is where I start seeming to have problems. I can open /proc/*/mem & lseek, but reads come back as "No such process". However, if I first do a ptrace(PTRACE_ATTACH), then I can read the data, but the process stops. I've kind of dug through the sys_ptrace() code under /usr/src/linux/arch/i386/kernel/ptrace.c, and can see and understand generally what it's doing, but that's getting into serious kernel-land stuff. I wouldn't expect it to be this difficult to just open up another processes /proc/*/mem file to read data from. Is there something obvious I'm missing? It seems to keep pointing back to ptrace & /proc/*/mem are very closely related (ie: the same) including stopping of the child. Thanks. --Rich