18:28 <mjacob> It turns out that using revdb is not as helpful for that use case as I hoped.

18:29 <mjacob> One problem is that two runs diverge on low-level details quite fast. E.g. a lot of dict keys are dependent on the memory address. Even if that does not usually change processing order, it can cause __eq__ to be called a different number of times because two runs have different hash collisions.

18:35 <mjacob> For debugging the full run of the translator, it’s not super useful because it takes over 2h per run. On replay, revdb creates fork points to be able to “jump back” in time. The current heuristic is quite simple (it has more fork points at the end, which is very useful to debug crashes that happened near the end, but not as useful for jumping back in the middle of the run).

18:37 <mjacob> Also, it can not be used to debug all kinds of reproducibility issues because it turns off some address randomization (that is required to be able to replay).

18:48 <mjacob> cfbolz: I found some cases where backend optimizations sort lists according to their members’ addresses. They use lists of (key, element) tuples in order to sort according to `key`. These can easily be fixed by passing a key function to sort(). I’m going to add you as a reviewer, as you are pretty much the only person having touched that code in recent years. I’m however unsure how to test these fixes.