So, initially, process A created a file containing data (37 Bytes) read from a stream(UART).
Process B has to acquire that data, which is stored in /dev/shm.
Process A has an absolute maximum of 4ms to write that file. Exceeding this results in inacceptable data loss. The file creation takes an average of 600us, which is perfectly fine wouldn't it spike randomly to 7ms and higher.
To avoid the file handling I wanted to access the RAM directly, by passing the array's address as startparameter:
// Process A
sprintf(cmd, "path_to_file.out %i", (unsigned int)&rx_buffer);
system(cmd);
// Process B
int rx_buffer_address = atoi(argv[1]);
Using Gilles suggested procedure, I was able to read once
sprintf(mem_file_name, "/proc/%d/mem", pid);
mem_fd = open(mem_file_name, O_RDONLY);
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
waitpid(pid, NULL, 0);
lseek(mem_fd, offset, SEEK_SET);
read(mem_fd, buf, _SC_PAGE_SIZE);
ptrace(PTRACE_DETACH, pid, NULL, NULL);
Running this approach repeatedly fails at the second attempt with open() returning ENOENT(No such file or dir) and ptrace returning ESRCH(No such process), even when adding close(mem_fd) to the function.
Further investigation has shown that the very first PTRACE_DETACH call already returns ESRCH.
Looking up ptrace(), I tried to read the memory with PTRACE_PEEKDATA, which returns 0xFF for every read.
Is the region accessed by the PEEKDATA method mapped differently than the /mem file descriptor? Or am I missing anything else regarding both methods or even the spiking file access times?
/proc
are identical to the restrictions on a process ptracing another process. And a process can only be ptraced by one process at a time. If you can include your code so that we can reproduce the problem, that will help a lot. – Mark Plotnick Jun 03 '16 at 19:55