Image for post
Image for post

If a program overwrites its own program counter register, it is almost impossible to recover using a conventional debugger — without the program counter, the debugger cannot figure out which function the program was running, and so cannot even give any useful information about what is on the stack or where the code was immediately before the stack was corrupted. This makes debugging pretty much impossible.

With a reverse debugger however, recovery is almost comically simple. You can simply do:

reverse-step

- to rewind one instruction, and the state of the program will move back to the instruction that corrupted the program counter, allowing you to see what’s gone wrong. This will also allow the debugger to know what function was running and so be able to interpret the stack and display it to you in a useful way. You can replay your code and subsequently find the issue in order to then debug and fix it quickly. …


Debug different with UDB for C/ C++

What do we know about debugging? Most of us know it’s painful, stressful and takes up too much of our time when we just want to build things.

We also know it is becoming increasingly harder for developers to debug software due to complex orchestrations and architectures that make understanding program behavior much harder.

The Cambridge dictionary describes the meaning of the verb ‘debug’ as follows:

"to remove bugs (= mistakes) from a computer program".

And how do we do this? By investigating what it was that went wrong and caused our program to blow up, crash or throw errors.

To find the root cause of bugs we need to work backward ⏪

Like a detective trying to solve a mystery, the natural thing to do when debugging is to follow the evidence…backward. We need to follow the trail of clues and step backward to find out where exactly in our code the mistake or error is occuring. …


Image for post
Image for post

Last time we looked at user-defined commands in the GDB command-line. In this GDB tutorial, we look at writing our user-defined functions in Python.

In this tutorial, Greg Law shows you how to write user-defined GDB commands in Python.

The advantage of creating user-defined commands in Python is that you can automate a more complicated task or something that you might want to check into source control and share with your teammates. Using Python is more robust too; it’s more extensible and although a bit more work, it gives you better results in multiple ways.

Boilerplate to get you started

Let’s start with the initial boilerplate for our Python code. We write it in a file; bugreport.py. …


Developers can now use LiveRecorder to record, replay and reverse-debug Java applications seamlessly in IntelliJ IDEA.

Image for post
Image for post
Software Failure Replay — record and replay debugging

Today we are excited to share the launch of LiveRecorder for Java with you!

LiveRecorder for Java is a transformational set of developer productivity tools, that enable Java developers to resolve bugs much faster than before. It simplifies the traditional and lengthy process of debugging complex Java applications, down to 3 simple steps — Record, Replay, Resolve.

LiveRecorder for Java is a Software Failure Replay platform that supports the recording, replaying and reversible debugging of Java application software. A recording captures a failing process down to instruction level. Developers debugging Java applications get an automatic 100% reproduction of the error that caused the failure. …


In this GDB tutorial, we’re going to look at user-defined commands.

There are various reasons you might want to work with user-defined commands; but one of the most prominent is that we want to be productive. For example, if we’re doing something repetitive, then it’s good to automate it; we spend less time doing the task, and of course, we make fewer mistakes once we get it right.

GDB versus the Python way

Two ways to automate things in GDB:

  1. Use the perhaps a bit old fashioned built-in user-defined GDB commands.
  2. Or, use the slightly more modern Python way of doing it.

Both options have their place. …


The explosion of Agile development and DevOps practices has resulted in more frequent testing to enable faster and continuous delivery of software applications. That’s the theory anyway.

A study carried out recently by a Cambridge Judge Business School MBA project reveals that while the adoption of continuous integration is on the rise (growing from 70% in 2015 to 88% in 2019), software failures in QA & test still detrimentally affect delivery speed. This is the Great Stink in software development.

In this post, we’re going to talk about what development teams can do to make the problem of failing tests go away.


Image for post
Image for post

If you use Microsoft Visual Studio for your coding, then Visual Studio can debug on Linux using Windows Subsystem for Linux (WSL) and GDB.

The WSL lets you run a GNU/Linux environment, including most command-line tools, utilities, and applications, directly on Windows, unmodified, without the overhead of a virtual machine.

In this GDB tutorial, I’ve asked Microsoft Developer Advocate Sy Brand to show you how.

Setup for GDB debugging

To install WSL, go to https://AKA.MS/WSL on your web browser. Just follow the instructions to get a full installation of your favorite Linux distribution.

When you are back in your code, go to My Configurations, click on Manage Configuration, and add a new configuration so you can target WSL right from Visual Studio. Scroll down the list to find the WSL-GCC-Debug, and that allows a new target. …


For this GDB tutorial, I invited my good friend Phil Nash to show CLion’s less known GDB command features. Phil is a developer at JetBrains.

CLion is an Integrated Development Environment (IDE) for C and C++. GDB and LLDB fully integrate with CLion. You may not even know that GDB runs under the hood, so I thought that this is an excellent opportunity to explore how you can optimally leverage GDB in CLion.

Over to you Phil.

Integrated debugger

As Greg said, you may not even know that GDB or LLDB runs under the hood. CLion most likely picked up your toolchain when you installed it. …


Image for post
Image for post

We are massively excited to share that LiveRecorder for Java now has an early access beta program. LiveRecorder for Java supports the recording, replaying and reverse debugging of Java applications.

From day one, it’s been our product philosophy to focus on making LiveRecorder something that empowers developers to resolve software failures faster more easily. Armed with your feedback and our experience we aim to transform the 30+ year-old paradigm of how we detect and resolve software errors.

To achieve that, we’re committed to releasing early access versions of our products. This enables us to stay in tune with developers, get valuable feedback and to understand their workflows, as part of continuously improving the product. …


With new social distancing measures and most people now being advised to work from home, what do you do when a key customer reports a failure with your software in production?

Traditional production troubleshooting

Today, your debugging workflow might look like this:

  • Get initial description of problem from customer
  • If issue cannot be resolved remotely, send Field Application Engineer or developer on customer site
  • FAE or dev reviews issue, using artefacts such as logs or core dumps
  • If issue cannot be resolved at this point, an R&D engineer is assigned
  • Logs, core dumps and/or other information is fed back to the R&D engineer for…

About

Undo Bytes

LiveRecorder is an enterprise software failure replay platform. We help developers Record, Replay & Resolve bugs & accelerate MTTR. https://undo.io

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store