Programmatic Debugging: Part 1 the challenge

As every developer knows, debugging an application can be difficult and often enough you spend as much or more time debugging an application as originally writing it. Every programmer develops their collection of tools and techniques. Traditionally these have included full-fledged debuggers, instrumentation of the code, and tracing and logging. Each of these has their particular strengths and weaknesses.

Continue reading “Programmatic Debugging: Part 1 the challenge”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Debugging .NET on Red Hat Enterprise Linux from Visual Studio

Being able to edit your C# (or F# for that matter) code on your Linux VM from Visual Studio in Windows is pretty great. As a Windows developer, you’re able to work in an environment you know and trust while still being able to experiment — and hopefully produce production code — in Linux, where you may not be quite up to speed. Yet. Visual Studio, that familiar, productive and helpful IDE, is at your fingertips even though your code is far away in a Linux VM.

(Okay, not that far; the VM is running on the Red Hat Container Development Kit on your Windows box, but let’s call that last sentence “poetic license” and move on.)

Editing isn’t enough; we all know that. Since code sometimes has bugs (cough), we need to debug our code. Sure, we can write to a log and check inputs and outputs against expected results, but even that’s not enough. Any kinds of tests, even automated tests (you are using TDD, right? Right?) only confirm the existence — as rare as they are in your code — of defects. Finding the cause of a defect, ahhhh … there’s the rub. If only we could run interactive debugging from within Visual Studio against our compiled C# code running in our RHEL VM.

Well guess what; We can. It’s called “offroad debugging” and it’s not difficult to set up and — this is a technical term — it’s very cool. It’s a bit of work to get set up — not difficult, just several steps — but after doing it one time it becomes very easy for future projects. And never forget; if you get stuck, you can reach me on Twitter (@DonSchenck) or email me at dschenck@redhat.com.

Continue reading “Debugging .NET on Red Hat Enterprise Linux from Visual Studio”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Debugging Java Applications using the Red Hat Container Development Kit

Containerization technology is fundamentally changing the way applications are packaged and deployed. The ability to create a uniform runtime that can be deployed and scaled is revolutionizing how many organizations develop applications. Platforms such as OpenShift also provide additional benefits such as service orchestration through Kubernetes and a suite of tools for achieving continuous integration and continuous delivery of applications. However, even with all of these benefits, developers still need to be able to utilize the same patterns they have used for years in order for them to be productive. For Java developers, this includes developing in an environment that mimics production and the ability to utilize common development tasks, such as testing and debugging running applications. To bridge the gap developers may face when creating containerized applications, the Red Hat Container Development Kit (CDK) can be utilized to develop, build, test and debug running applications.

Red Hat’s Container Development Kit is a pre-built container development environment that enables developers to create containerized applications targeting OpenShift Enterprise and Red Hat Enterprise Linux. Once the prerequisite tooling is installed and configured, starting the CDK is as easy as running the “vagrant up” command. Developers immediately have a fully containerized environment at their fingertips.

More information on the Red Hat Container Development can be found Red Hat Developers, and on the Red Hat Customer Portal

One of the many ways to utilize the CDK is to build, run, and test containerized applications on OpenShift. Java is one of the frameworks that can be run on OpenShift, and these applications can be run in a traditional application server, such as JBoss, as well as in a standalone fashion. Even as runtime methodologies change, being able to debug running applications to validate functionality remains an important component of the software development process. Debugging a remote application in Java is made possible through the use of the Java Debug Wire Protocol (JDWP). By adding a few startup arguments, the application can be configured to accept remote connections, for example, from an Integrated Development Environment (IDE) such as Eclipse. In the following sections, we will discuss how to remotely debug an application deployed to OpenShift running on the CDK from an IDE.

Continue reading “Debugging Java Applications using the Red Hat Container Development Kit”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

A Lesson in Debugging: Big Projects Have Critical Bugs Too

I recently had an interesting problem which served as a great learning experience. It involves hair-pulling levels of frustration, vicious finger-pointing, and an unexpected ending — not a TV Soap opera episode, just a day in the life of a developer.

It all started with a REST API I had built for a customer proof of concept that started refusing requests after an arbitrary period of time. Nothing was unusual in the codebase of the REST API — it was two simple CRUDL endpoints on equally simple objects.
I’d built similar many times before, and probably will many times again – but yet still, this process kept hanging, refusing requests. The time it took to fail was arbitrary — sometimes immediate, sometimes hours, sometimes days.

Eventually, through some SSH foo we discovered that the count of open file descriptors was growing inside the app’s container. I wrote a simple endpoint to query the number of open file descriptors, and it looked like this:

app.get('/fd', function(req, res){
  var fs = require('fs');

  fs.readdir('/proc/self/fd', function(err, list) {
    if (err) {
      return res.status(500).json(err);
    }
    return res.end(list.length.toString());
  });
});

Indeed, after restarting the process, it was clear that the file descriptor count would grow every few minutes, without stopping. An empty Node.js application didn’t exhibit the same problems, only this app.

Continue reading “A Lesson in Debugging: Big Projects Have Critical Bugs Too”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

LTTng Packages now Available for Red Hat Enterprise Linux 7

EfficiOS is pleased to announce it is now providing LTTng packages for Red Hat Enterprise Linux 7, available today as part of its Enterprise Packages portal.

EfficiOS specialises in the research and development of open source performance analysis tools. As part of its activities, EfficiOS develops the Linux Tracing Toolkit: next generation for which it provides enterprise support, training and consulting services.

What is tracing?

Tracing is a technique used to understand the behaviour of a software system. In this regard, it is not far removed from logging. However, tracers and loggers are designed to accommodate very different use cases.

Continue reading “LTTng Packages now Available for Red Hat Enterprise Linux 7”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Remote debugging with GDB

gnu logoThis past few weeks I’ve been working on making remote debugging in GDB easier to use. What’s remote debugging? It’s where you run GDB on one machine and the program being debugged on another. To do this you need something to allow GDB to control the program being debugged, and that something is called the remote stub. GDB ships with a remote stub called gdbserver, but other remote stubs exist. You can write them into your own program too, which is handy if you’re using minimal or unusual hardware that cannot run regular applications… cellphone masts, satellites, that kind of thing.  I bet you didn’t know GDB could do that!

If you’ve used remote debugging in GDB you’ll know it requires a certain amount of setup. You need to tell GDB how to access to your program’s binaries with a set sysroot command, you need to obtain a local copy of the main executable and supply that to GDB with a file command, and you need to tell GDB to commence remote debugging with a target remote command.

Until now.

Continue reading “Remote debugging with GDB”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Querying DWARF For Fun And Profit

dwarfDebugging information provides a view into the source code of an application. It’s by no means exhaustive, but many features present in the source code are present in the debugging information as well: translation units, functions, scopes, types, variables, etc. It is essential to a range of tools: GDB, SystemTap, OProfile, as well as various developer aids (such as pahole or libabigail).

So clearly this data can be a useful source of information (hence the name, after all). But the only way to access it is through a dumping tool—such as dwarfdump or {eu-,}readelf -w. Deriving any sort of relationship from a dump is a very clumsy undertaking that usually requires nontrivial amounts of scripting to glue the disparate pieces together.

A new tool that Red Hat has been working on lately addresses the need to query debugging information in a structured manner. It is called dwgrep (DWARF grep). As the name indicates, it’s aimed particularly at DWARF, which is the name of the format that’s generally used in Linux for representing debugging information.

There are two major families of use cases. The first is automated checking of generated DWARF. This comprises looking for instances of a known bug when trying to gauge its impact, discovery of an obscure DWARF construct to check a DWARF consumer that you are writing, or testing DWARF for structural soundness.

Continue reading “Querying DWARF For Fun And Profit”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

GCC Undefined Behavior Sanitizer – ubsan

Not every software bug has as serious consequences as seen in the Ariane 5 rocket crash. Notwithstanding that, bugs cost software companies a lot of money every year and upset customers, users, and developers. Some bugs happen as a result of undefined behavior occurring in the program. Undefined behavior is a concept known especially in the C and C++ languages which means that the semantics of certain operations is undefined and the compiler presumes that such operations never happen. For instance, using non-static variable before it has been initialized is undefined. If an undefined behavior occurs, the compiler is free to do anything. The application can produce wrong results, crash, or print the complete text of Proust’s oeuvre.gnu logo

Luckily, there are ways to detect at least some of the undefined behavior in a program. The compiler can issue a warning at compile time, but only in case it can statically detect some kind of wrongdoing.  Often this is not the case and the checking has to take place at run time.

Enter ubsan

Continue reading “GCC Undefined Behavior Sanitizer – ubsan”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Find and fix nasty memory bugs with Developer Toolset's memstomp tool

One of the really useful tools provided by Red Hat Developer Toolset v2.x is “memstomp“, which helps you identify a particularly nasty class of bug in applications built (directly or indirectly) from C/C++ code so you can then fix them before your customers experience problems. In this brief article, I’ll explain the background for the tool, how to get it, how to use it yourself and briefly how it works.

Background

The memcpy() routine in the standard C library has a long and storied history, stretching back through POSIX and ISO standards into the early history of the modern computing era. It’s a simple little routine that does one simple task required in a variety of scenarios – it copies a specified number of sequential bytes from one location in memory to another. You tell it where to start copying from, how many bytes to copy and where to copy to. Simple.

Continue reading “Find and fix nasty memory bugs with Developer Toolset's memstomp tool”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.