Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

github.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#53

Post by Veserv »

__init wrote: post #49
JoeAltmaier wrote: post #47

Neat! Years and years ago I had the opportunity to give Intel processor designers (the time of the 386!) requests for features. I requested a system tick timer for stamping logs (they did that), bus mask and value registers that triggered a debug interrupt on a match (they did that). And a jump source history. Maybe 10 jumps back. So on a breakpoint you could figure out how you got there. A time travelling debug feat…

Intel x86 cores have had Last Branch Records (LBRs) and Branch Trace Store (BTS) since at least Merom in 2006 [1][2]. Nowadays, there's Processor Trace (PT) or Precise Event-Based Sampling (PEBS) which can provide even more information. PT in particular is almost purpose-built to enable this kind of trace reconstruction. [1] https://stackoverflow.com/questions/14670586/what-is-the-ove... [2] The MSRs for LBRs (MSR_LA…

Those are only sufficient to produce a execution trace rather than a full data trace which is needed for time-travel debugging.

Though they are sufficient to do what the person you responded to asked for which is just execution trace.

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#54

Post by Veserv »

alehander42 wrote: post #14
rubenvanwyk wrote: post #5

Looks really cool, but in production systems, won't the trace files proliferate at extreme speed? How would you correlate the files to a certain session for user identification for example?

We are also planning to develop a distributed tracing platform, similar to Jaeger and OpenTelemetry, that continuously records the execution of many distributed processes (e.g. micro-services). Unlike the existing platforms, which capture only message flows and require you to make educated guesses when some anomaly is observed, our system will let you accurately replay the processing code for each message to quickly…

You can not just discard the oldest data of a long-running execution trace when doing replay-based time-travel debugging.

You can not replay execution without a known state followed by all non-determinism after that state which is most easily done by starting from the initial state. To discard data, you need to manifest a state snapshot corresponding to that time to enable forward reconstruction from that state.

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#56

Post by phire »

JoeAltmaier wrote: post #47

Neat! Years and years ago I had the opportunity to give Intel processor designers (the time of the 386!) requests for features. I requested a system tick timer for stamping logs (they did that), bus mask and value registers that triggered a debug interrupt on a match (they did that). And a jump source history. Maybe 10 jumps back. So on a breakpoint you could figure out how you got there. A time travelling debug feat…

I'm not entirely surprised, adding 40 bytes of SRAM to the 386 for a debug-only feature would have been hard to justify.

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#58

Post by alehander42 »

Veserv wrote: post #54
alehander42 wrote: post #14

Earlier quoted context omitted.

We are also planning to develop a distributed tracing platform, similar to Jaeger and OpenTelemetry, that continuously records the execution of many distributed processes (e.g. micro-services). Unlike the existing platforms, which capture only message flows and require you to make educated guesses when some anomaly is observed, our system will let you accurately replay the processing code for each message to quickly…

You can not just discard the oldest data of a long-running execution trace when doing replay-based time-travel debugging. You can not replay execution without a known state followed by all non-determinism after that state which is most easily done by starting from the initial state. To discard data, you need to manifest a state snapshot corresponding to that time to enable forward reconstruction from that state.

you're right: in the RR case: currently this is not merged yet, but a RR contributor works on persistent checkpoints; they can act as snapshots

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#59

Post by tester756 »

Hi alehander42

I've been searching for something like this, so my question is

I have almost identical program in version 1 and 1.01 and I need to find how their behaviour changed

So, I run both of them ./binary1.exe input.txt ./binary2 input.txt and record their execution with your tool

And now, I'd want to extract such data from your tool:

Visited functions and how locals were changing. e.g

int test(int n) {

    n++;

    std::cout  22)
    {
      n--;
    }
    return n + 1;
}

int main(int argc, char* argv) {

    auto result = test(argv[1]);

    std::cout
}

Visited Function: main with arguments (argc: 2, argv ["path", 7])

Visited Function test with arguments (n: 7)

test: N set to 8

test: N set to 23

test: Entered If (n > 22):

N set to 22

Exit If (n > 22)

test: N set to 23

Exit function test

Main: result set to 23

Exit function main

Can I achieve it with your tool / recording data format?

Post reply on HN