5 ms·

Get `udb` - the reversible/time-traveling debugger from Undo. I don't own any stock - I love their product. You can run your code within it, hit an error, set a

Get `udb` - the reversible/time-traveling debugger from Undo. I don't own any stock - I love their product. You can run your code within it, hit an error, set a watch-point, reverse-continue to where the watch-point memory was changed and then check the stack. udb will turn brain-melting, blood-freezing memory bugs into trivial problems that you can solve in a few minutes.

wooosh 4y ago
A similar project is rr[0], which is freely available. Like you said, I find that reversible debuggers are a huge improvement over regular debuggers because of the ability to record an execution and then effectively bisect the trace for issues. [0]: https://rr-project.org/ https://rr-project.org/
dleslie 4y ago
gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks?
- leni536 4y ago
  I'm not familiar with udb, only with rr. Compared to rr, gdb's recording for reversible debugging is tremendously slower. However rr has strict requirements for the CPU (didn't work on AMD, the last time I looked) and requires some permissive perf_event_paranoid setting to run. In my experience rr's recording is around x2 slower for single threaded programs than running the program on its own. I think featurewise they are in parity. I heard that udb is like rr, but better on some fronts (except price and software freedom).
- mark_undoio 4y ago
  (I work for Undo) > gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks? GDB's built-in reversible debugging is cool (and it's helped raise awareness) but it doesn't scale well. We build on the same command set and serial protocol that GDB defined - UDB is GDB but with additional Python code hooking it up to our separate record/replay engine. For UDB, I'd say we offer: 1. Performance & efficiency (orders of magnitude faster at runtime and lower in memory requirements). 2. Recordings can be saved to portable files (share with colleagues, receive from customers, etc). 3. Library API so applications can self-record with control of when to capture and save. 4. Wider support of modern software (proactively tracking modern CPU features, shared memory and device maps, etc). 5. Correctness (in the past we've found the reverse operations in GDB don't have as strong semantics as we'd hoped, though I'd also be happy to be wrong here) FWIW, rr (https://rr-project.org/ https://rr-project.org/) also offers many similar benefits over GDB's built-in system (though not the library API in point 3) but with differences in what CPUs / systems are supported, ability to attach at runtime, etc. If you're looking for an open source solution, I'd choose rr over GDB's built-in approach.
- roca 4y ago
  gdb's built-in recording slows down the debuggee by about 1000x, rr more like 2x. That makes a huge difference in practice. rr's recording works across system calls, thread context switches, etc, but gdb's doesn't. rr's recording creates a persistent recording on disk that you can even move around between machines. This permits workflows that gdb's doesn't. (Disclaimer: I work on rr)
chubot 4y ago
(author here) Yes I tried reversible debugging a couple years ago, but at the time I didn't have any bugs that needed it :) I managed to get by here without it, but it's a technique I'd like to be more familiar with I'm on the Undo mailing list as well -- nice to see that it's effective! (Also should say that Clasp sounds very cool -- I'm a fan of anything that enables interop and reuse, rather than rebuilding the same thing in different languages, which may or may not be as good)
- drmeister 4y ago
  Thanks! I'm very interested in a new garbage collector that works with C++. I have a long list of requirements we need that is currently satisfied by the Boehm garbage collector and were satisfied by the Memory Pool System before we moved away from it. I've been looking at the Memory Management Toolkit (MMTk). Where would you put Oil in that small club of memory managers?
  - aidenn0 4y ago
    I've been following along the gc of oil. It succeeds because it only solves the GC problems that Oil has (and I mean this as a high complement). Oil is single threaded, code runs in loops that are well understood, and the code is generated from a strongly typed subset of Python. The GC then is run only between loop iterations, so there is no need for stack scanning. You never have to worry about a root being in a temporary (from the point of view of the C++ compiler) since there are just a few locals in the function running the loop, and any variables local to the loop are logically dead between iterations. Since a goal of Oil is portability, not scanning registers and stacks is very important. Getting this right when the GC could be invoked at any allocation is potentially intractable with mypy semantics at least.
    - drmeister 4y ago
      Ah - thank you. We are looking for a GC that supports (in no particular order): (1) conservative stack scanning, object pinning. (2) optionally conservative and precise on the heap. (3) compacting when precise. (3) weak pointers. (4) good multithreaded performance. (5) finalizers. (6) ability to create pools of different kinds of objects - especially cons cells (pairs).
mark_undoio 4y ago
In our latest release of UDB we added the `last` command: https://docs.undo.io/TrackingValueChanges.html https://docs.undo.io/TrackingValueChanges.html Which effectively combines a `watch -l`, plus a reverse-continue but also monitors when the underlying memory was allocated / freed. It's quite nice, basically "git blame" for your variables.

wooosh 4y ago

A similar project is rr[0], which is freely available. Like you said, I find that reversible debuggers are a huge improvement over regular debuggers because of the ability to record an execution and then effectively bisect the trace for issues. [0]: https://rr-project.org/ https://rr-project.org/

dleslie 4y ago

gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks?

leni536 4y ago
I'm not familiar with udb, only with rr. Compared to rr, gdb's recording for reversible debugging is tremendously slower. However rr has strict requirements for the CPU (didn't work on AMD, the last time I looked) and requires some permissive perf_event_paranoid setting to run. In my experience rr's recording is around x2 slower for single threaded programs than running the program on its own. I think featurewise they are in parity. I heard that udb is like rr, but better on some fronts (except price and software freedom).
mark_undoio 4y ago
(I work for Undo) > gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks? GDB's built-in reversible debugging is cool (and it's helped raise awareness) but it doesn't scale well. We build on the same command set and serial protocol that GDB defined - UDB is GDB but with additional Python code hooking it up to our separate record/replay engine. For UDB, I'd say we offer: 1. Performance & efficiency (orders of magnitude faster at runtime and lower in memory requirements). 2. Recordings can be saved to portable files (share with colleagues, receive from customers, etc). 3. Library API so applications can self-record with control of when to capture and save. 4. Wider support of modern software (proactively tracking modern CPU features, shared memory and device maps, etc). 5. Correctness (in the past we've found the reverse operations in GDB don't have as strong semantics as we'd hoped, though I'd also be happy to be wrong here) FWIW, rr (https://rr-project.org/ https://rr-project.org/) also offers many similar benefits over GDB's built-in system (though not the library API in point 3) but with differences in what CPUs / systems are supported, ability to attach at runtime, etc. If you're looking for an open source solution, I'd choose rr over GDB's built-in approach.
roca 4y ago
gdb's built-in recording slows down the debuggee by about 1000x, rr more like 2x. That makes a huge difference in practice. rr's recording works across system calls, thread context switches, etc, but gdb's doesn't. rr's recording creates a persistent recording on disk that you can even move around between machines. This permits workflows that gdb's doesn't. (Disclaimer: I work on rr)

chubot 4y ago

(author here) Yes I tried reversible debugging a couple years ago, but at the time I didn't have any bugs that needed it :) I managed to get by here without it, but it's a technique I'd like to be more familiar with I'm on the Undo mailing list as well -- nice to see that it's effective! (Also should say that Clasp sounds very cool -- I'm a fan of anything that enables interop and reuse, rather than rebuilding the same thing in different languages, which may or may not be as good)

drmeister 4y ago
Thanks! I'm very interested in a new garbage collector that works with C++. I have a long list of requirements we need that is currently satisfied by the Boehm garbage collector and were satisfied by the Memory Pool System before we moved away from it. I've been looking at the Memory Management Toolkit (MMTk). Where would you put Oil in that small club of memory managers?
- aidenn0 4y ago
  I've been following along the gc of oil. It succeeds because it only solves the GC problems that Oil has (and I mean this as a high complement). Oil is single threaded, code runs in loops that are well understood, and the code is generated from a strongly typed subset of Python. The GC then is run only between loop iterations, so there is no need for stack scanning. You never have to worry about a root being in a temporary (from the point of view of the C++ compiler) since there are just a few locals in the function running the loop, and any variables local to the loop are logically dead between iterations. Since a goal of Oil is portability, not scanning registers and stacks is very important. Getting this right when the GC could be invoked at any allocation is potentially intractable with mypy semantics at least.
  - drmeister 4y ago
    Ah - thank you. We are looking for a GC that supports (in no particular order): (1) conservative stack scanning, object pinning. (2) optionally conservative and precise on the heap. (3) compacting when precise. (3) weak pointers. (4) good multithreaded performance. (5) finalizers. (6) ability to create pools of different kinds of objects - especially cons cells (pairs).

mark_undoio 4y ago

In our latest release of UDB we added the `last` command: https://docs.undo.io/TrackingValueChanges.html https://docs.undo.io/TrackingValueChanges.html Which effectively combines a `watch -l`, plus a reverse-continue but also monitors when the underlying memory was allocated / freed. It's quite nice, basically "git blame" for your variables.