Every once in a while I have to fix a bug that really drives me crazy. When this happens I usually recall one morning in the Computer Lab, back in college, one of my professors saying: “It doesn’t matter what you do, it doesn’t matter if you get upset or mad. You won’t beat the computer”. That morning I didn’t understand what he was trying to say. Actually I thought he was making fun of us. Foolish Mario, he wasn’t trying to do that. He was trying to advice us: to always stay calm.

Software Development could be stressful sometimes, if you write software you already know that. Even if you are an experienced programmer knowing the tools and loving writing software you will eventually face a situation, usually fixing a bug, that will drive you crazy and this gets worse when time is constrained, which usually is. At that time is when you have to breath deeply and evaluate every single piece of the puzzle. That’s when you begin enjoying the situation.

Software programmers like to fix, create and understand stuff, specially people with technical background, like me. We are also kind of masochists and we never give up. In my case I like saving those tips because I’m certain that I will need that information in the future.

The following is a list of tips that I wanted to share (and save!) and might be useful when debugging and/or writing software on Linux. Almost all tips are for debugging shared libraries however most of them will work for anything else besides shared libraries. There might be similar alternatives for the other OSs, I’m not sure though.

LD_DEBUG

If you write shared libraries or if have built any package from source you might be familiar with LD_LIBRARY_PATH, an environment variable meant to be used for specifying directories where to search libraries first, recommended for development and testing, nothing else. Well there’s another environment variable called LD_DEBUG, really useful for debugging. It basically outputs all dl* function calls. Use LD_DEBUG=help command for help.

nm and objdump

GNU Binutils is fascinating and has several utilities, however most of the time you will use only those two commands. Reading the manual is the best way to understand them. Basically they help you by listing the symbols used and exported in object files. I’ve used this two commands to make sure the final file, after linking, doesn’t reference to any other library I don’t need, and to make sure my shared libraries export the functions that were meant to export.

stop-on-solib-events

One of the hidden gems of gdb. Setting stop-on-solib-events to 1 will allow you to pause the execution of your program when a shared library is loaded. Really useful to know why is my shared library loaded twice? or who is loading what library?. See the other commands to specify files.

ldd and pmap

These are quite similar, both somehow tell you dependencies. The main difference is that ldd shows what libraries are required and pmap shows you process memory mapping, this means memory used and what libraries are actually used for the program.

strace

Traces all calls and signals used by the program. Using -e to define expressions is required unless you want to see lines and lines of calls. It could be useful if you want to profile you program.

valgrind

Required for profiling. In my previous job I used a lot since all applications were running 24×7 and memory was one of the most important things. I usually leave the application running for days using the following arguments: –leak-check=full –leak-resolution=high –show-reachable=yes then I comeback ctrl+c and I see the results.

Something else?

I’m sure I’m missing more commands, some of them language/platform-specific however I’m also sure this list will help me recalling what to check first when debugging shared libraries.

References

• Programming Howto
• Binutils
• Debugging with gdb
• Valgrind 3.3 – Advanced Debugging and Profiling, you can buy the book on Amazon too.

By Claire L. Evans / CC BY-ND 2.0

This is an updated version of Multiple Parallel Mono Environments.

What is Pulque?

Pulque is a collection of applications written in Ruby and Bash scripting to maintain parallel development environments.

Why does Pulque exist?

Three reasons:

1. I need to keep multiple versions installed of the same software,
2. I need to know what Version Control System is used by the software, and the most important
3. I want to keep myself sane.

At work, I have to interact with different open source projects, most of them use Subversion and Git, but some others use Bazaar and Mercurial. Keeping track of the current parallel development environment and the VCS used by the software is exhausting.

You spend time focusing on something that shouldn’t be that important:

• Managing your parallel environments and,
• Keeping track of the VCS used by the software

Is easy to get confused when interacting with the repository, for example, executing svn update when the software is stored in a git repository. Is silly, but it happens. Unless you are using an IDE that support Multiple Parallel Development Environments you will need the terminal to configure and build your projects.

Pulque helps you maintaining parallel development environments by:

• Printing in the bash prompt the name of the parallel development environment and the type of the VCS, this information is updated depending on the working directory,
• Defining aliases to the default commands used to configure and build the software project, to always prefix your projects using your parallel environment, and
• Showing a failure or success alert when the command finishes.

Installing and using Pulque

Follow the instructions in INSTALL, or if you are using openSUSE 11.2:

Click here to drink Pulque!

Don’t forget to add the function pswitch to your .bashrc. Bash will autocomplete your environment name when using TAB TAB.

function pswitch {
  source /usr/bin/__pswitch $1
}

Read the USING file to understand how to use Pulque in the daily basis. If you find something weird or interesting please create an issue to fix it.

Colophon

According to Wikipedia: “Pulque, or octli, is a milk-colored, somewhat viscous alcoholic beverage made from the fermented sap of the maguey plant, and is a traditional native beverage of Mexico.“

A couple of days ago I finished reading: The Ruby Programming Language, book written by David Flanagan and Yukihiro Matsumoto. If I have to say anything about the book and, the language, of course, is: I am impressed. The syntax is pretty for writing and simple for reading. Its simplicity makes you understand the code, is like visualizing the goal of the program in your mind by reading it, not running it. It is like reading a well written letter. You just understand.

I must say, when I was reading the book, at the beginning. I did not feel comfortable with the weird, at that time, syntax. Method decorations such as “!” and “?”, and the support for methods aliases made no sense. Actually I thought I was wasting my time by trying to learn the language. I was wrong.

When I learned C++ several years ago, I did not have reference to object orientation or any object-oriented programming language. Learning it was difficult, but, at the same time, easy. Difficult because I did not know the paradigm, easy because it was my first time learning that kind of syntax. After learning C++ I decided to learn Java and after that, I decided to learn C#.

And I learned them all the same way. I “translated” the syntax. Translated it from the “new language” to the “old language”. I did learn them all. And I thought, for long time, that the rule was: “Learn all the languages the same way: by translation”. I was wrong. Again.

Learning a new programming language, in my opinion, is better when you do not translate the new language. Similar to learn to speak a new language. In both cases, you have to think in the language. I decided to think in the new language. To do it that way. The Ruby way. The results were amazing. Were so amazing that inspired me to write a project in Ruby. I wanted to try out the syntax, the platform and the community. To see if the language was that good as I thought.

After trying it out. No disappointments at all. Actually is interesting that C# and Ruby share a lot of things, syntactically speaking. Both of them are pretty languages. Probably they do not share goals. However, I’m sure they share one goal: to make the life of the software developer easier. And, to a software developer, a programming language, and everything around it, that makes your life easier is what matters the most.