Robert O'Callahan

I can't reproduce this on 5.14 with 200 runs on the testcase with rr chaos mode.

So according to your trace the last `epoll_wait` returns 0 fds ready after about 2 seconds of blocking: ``` { real_time:551471.654556 global_time:2103, event:`SYSCALL: epoll_wait' (state:ENTERING_SYSCALL) tid:2868900, ticks:5882250 rax:0xffffffffffffffda rbx:0x681fffa0 rcx:0xffffffffffffffff...

Something like that should work I guess. I'd need to think pretty hard to decide if what you're suggesting is optimal. Why do we need to store extra information in...

But why do we need to know that during replay?

Actually I guess I'm not understanding something. > Right, the information to record is which thread corresponds to the n in /proc/n/mem, since it may have no relation to anything...

Right, I understand that computing the tid of the target process in rr's pid namespace is a huge pain :-). I'm just saying that we're already storing that in the...

I think, in Linux 4.1+ at least, we can compute the (`pid-namespace-of-process`, `pid-of-process-in-its-pid-namespace`) pair for any process visible in any procfs by reading `/proc//ns/pid` and using the `NSpid` field of...

> Maybe, I'm misunderstanding something, but the pid in the namespace of the procfs mount, not the pid of the process in its own namespace. I don't understand what you're...

From `man proc`: ``` * NStgid : Thread group ID (i.e., PID) in each of the PID namespaces of which [pid] is a member. The leftmost entry shows the value...

So the rightmost value in `NSpid` gives you the pid of the process in its own namespace, regardless of which process is doing the reading or how the procfs was...