Tag: debugging

John Frizelle, a Mobile Platform Architect at Red Hat, gave a talk on microservices wherein he provided some great advice about microservices. Most importantly, he provided guidance on when, where, and why (or why not) you should deploy them.

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.

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.

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.

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.

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 RESTAPI 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 RESTAPI — 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:

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.

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.

This 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.