{"id":107107,"date":"2022-09-05T07:00:00","date_gmt":"2022-09-05T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107107"},"modified":"2022-08-31T07:18:55","modified_gmt":"2022-08-31T14:18:55","slug":"20220905-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220905-00\/?p=107107","title":{"rendered":"Is there any meaningful way to compare two Time Travel Debugging positions?"},"content":{"rendered":"

Time Travel Debugging<\/a> uses position objects<\/a> to represents points in the recorded debugging trace. A position object consists of two numbers (represented in hexadecimal) separated by a colon. The first number is a 64-bit number known as the sequence number<\/i>, and the second number is a 32-bit number known as the step number<\/i>.<\/p>\n

So if you have two position objects, is there a way to determine which one occurred first in the trace?<\/p>\n

Generally speaking, the position objects can be sorted chronologically by sequence number, and then by step within a sequence number.\u00b9 This ordering is valid even across traces from different processes running simultaneously on the same system. (The consistent cross-process ordering is handy when you are debugging a problem that spans multiple processes.)<\/p>\n

Roughly speaking, what you can say is that the first<\/i> step (step zero) of each sequence is chronological by sequence number. The remaining steps in the sequence proceed chronologically within the sequence, but chronological ordering between steps from different sequences is a bit fuzzier because multiprocessing is like that.<\/p>\n

For example, consider this timeline:<\/p>\n

\u00a0<\/div>\n\n\n\n\n\n
Thread 1<\/th>\n3:0<\/td>\n3:1<\/td>\n3:2<\/td>\n6:0<\/td>\n6:1<\/td>\n<\/tr>\n
 <\/td>\n<\/tr>\n
Thread 2<\/th>\n4:0<\/td>\n4:1<\/td>\n4:2<\/td>\n4:3<\/td>\n5:0<\/td>\n5:1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

At the start of the trace, thread 1 is assigned sequence number 3, and thread 2 is assigned sequence number 4. Thread 1 then executes instructions 3:0, 3:1, and 3:2. Meanwhile, thread 2 executes instructions 4:0, 4:1, and 4:2. Instructions do not all take the same amount of time to execute, so you can’t compare step numbers between sequences. In the above example, thread 1 executed some slow instructions, so it is stuck on step 2 (within sequence 3). while thread 2 is already on step 3 (within sequence 4).<\/p>\n

In the above trace, thread 2 concluded sequence 4 after four instructions, and its next sequence was assigned the number 5. A little while later, thread 1 concluded sequence 3 and it received sequence number 6 for its next sequence of instructions.<\/p>\n

So how does the Time Travel Debugger decide when to end a sequence and start a new one?<\/p>\n

Sequence boundaries occur at these points:<\/p>\n