Cool, but why do you have to disable ALSR for recording to work?
I've done similar things before – in PANDA we don't strictly need to snapshot the full device state when creating a recording; it would be enough to just keep track of which memory regions are I/O and reconstitute that mapping. But QEMU's savevm/loadvm saves and restores that mapping as a side effect so it's easier to just let that happen.
Edit: also, instead of disabling ASLR system-wide, it might be better to just use "setarch `uname -m` -R <pypy>", which disables it for just a single process.
As a practical matter, ASLR should have little if any impact to nearly all programs design, so disabling it at development/debug time should not come at a big cost.
BTW this post states "There is no fundamental reason for [ASLR] restriction, but it is some work to fix."
EDIT: I see, your focus is specifically on recording. Disregard this comment, good point.
> Only works on Linux, and only with Address Space Layout Randomization (ASLR) disabled. There is no fundamental reason for either restriction, but it is some work to fix.
print id(object())In the example given here, you could get away with it since control flow doesn't depend on the value of id(object()). But for example, if you had:
if (id(object()) >> 12) & 1:
print "foo"
else:
print "bar"
What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program.
Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic.
Thinking about this now, I realize disabling ASLR shouldn't be enough to fix this problem since recording and replaying are sufficiently different.
Ah yes, it needs to be deterministic in the context of a time-traveling debugger, I was thinking about the general case, sorry.
> Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic.
Surely it is, if you precisely know all timings and IO and can replay them there's nowhere for non-determinism to creep in.
That's not really an acceptable scale of required knowledge for a time-traveling debugger though.
This was my original point, the address space layout information leaks into python land via things like id.
> That's not really an acceptable scale of required knowledge for a time-traveling debugger though.
That's what recording captures (though, you don't need to know the times at which things happened).