Robert O'Callahan

So check `ulimit -a` and try increase that limit by an order of magnitude.

If you're building rr yourself you could try changing ``` do { ret = perform_remote_clone(remote, base_flags, stack, ptid, tls, ctid); } while (ret == -EAGAIN); ``` to add `|| ret...

I don't really have any idea then. It certainly sounds like you're hitting some limit but there are a lot of different limits in the kernel you could be hitting.

Maybe check `dmesg`?

I don't think those are relevant.

There is no cap. You can try increasing `checkpoint_interval_exponent`, to, say, 4. That will halve the number of checkpoints but increase the overhead of reverse execution.

Looks like this breaks tests with gdb?

I guess this is old and obsolete at least.

rr already has a notion of checkpoints. At the `Session` API level, `ReplaySession::clone` returns a `ReplaySession` that serves as a checkpoint. The returned session is "partially initialized", i.e. the thread...

For restoring checkpoints I think we need a static function in `ReplaySession` that's like `create` but takes two parameters: a `trace_dir` and a file descriptor for the opened checkpoint file,...