2

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?

mystery
  • 121
  • All those errors are consistent with process pid either exiting or (I'm less sure of this) being ptrace_ seized by another process. Could either of those have happened? – Mark Plotnick Jun 02 '16 at 18:40
  • I always double checked the pid, it was correct and running at all times. I would say the process being ptraced by the system is rather unlikely but my knowledge about linux is not deep enough for that. Even if that was the case, I should still be able to perform those actions, why would the kernel block me on these as they are all custom programs? – mystery Jun 03 '16 at 07:09
  • The restrictions on opening and reading/writing certain files in /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

0 Answers0