Help! I can’t debug!

I was just coming off of my holidays and thought that I should run a quick check of my mailbox to see what new and exciting things had transpired while I was away and blissfully ignorant of the comings and goings at the office.

What I found in my mailbox I found rather amusing.  I had four separate requests for help in getting the QNX debugger up and running using the IDE

I’m not doing (much) IDE development these days but these types of requests still manage to find their way to me because of my dogged insistance that I use our Momentics tools for all of my development and also because I think that printf  debugging is for dinosaurs.  If the IDE can’t get the job done for you, then we need to fix it so that it can … feel free to tell us so!

Anyway … back those e-mails.  They all were stating that they just couldn’t get the IDE debugger to work.  The platforms were all different (arm, sh, x86) and the environments were all different (Windows, Linux and Neutrino) but the problem was the same.  The application would launch, but the IDE debug session would fail with a cryptic connection error.

Why is this happening?  For most IDE services, the qconn target agent is all that needs to be up and running.  However, the debugger also makes use of the pdebug debugger target agent.  This is launched automatically for you when you start debugging. 

… unless it isn’t. 

The problem is that since the IDE is telling qconn to launch the pdebug program, pdebug needs to be in one of two places:

  • Accessible via qconn’s PATH environment variable
  • Located in /usr/bin/pdebug

If the pdebug debugger target agent can’t be launched, then the debug session will fail … and the resulting error message provides absolutely no indication of what is going on and why the debug session failed.

While this bit of information is recorded in the documentation for the IDE, it isn’t the first thing you would find when things go wrong.

So … if debugging wasn’t working for you and you never understood why and flipped back to printf’s take a close look at your configuration (and/or make sure that pdebug is in /usr/bin) and try it again … I think you’ll like it!



2 comments so far

  1. Mitchell Schoenbrun on

    I just have to respond to the “printf debugging is for dinosaurs” comment. Ok I’m a dinosaur, and I want to defend my practice. I’m not saying it is for everyone. First of all, I have plenty of experience using debuggers, all sorts, assembler level up to source code level. That’s part of the problem. I’ve probably used 7 or more different debuggers over the years, all with different syntax. Given the choice of learning, yet another debugger, and chewing razer blades, well you get the picture. That is not to say it might not be worth it, if debuggers provided me with something I needed. I used to occaisionally get “deep” bugs. Anyone whose been around code long enough knows what I’m talking about. Bugs that move when you put in a printf. Bugs where the appearance that something is wrong occurs long after the trigger that started it. Sometimes a debugger is invaluable for these types of bugs. Sometimes it is worth wading through the debugger docs, just to go after such a bug. But as I said, I used to get these bugs. I don’t seem to anymore. I cough that up to experience. I’m not trying to toot my horn here, but after a while, you learn how to avoid these types of problems. Mostly all I need to know these days is, what unexpected value does this variable have here. Once I know that, I can usually just look at the code and figure things out. I’m not even saying that what I do is faster than with a debugger, but the number of minutes I spend debugging is small compared to those I spend writing, so it really doesn’t matter.

  2. sendreceivereply on


    You aren’t going to hear me argue that “doing it right” the first time (whether it is by using experience, by methodical rigour) is going to help you stay away from debugging code in the first place.

    In my experience however, the developers who are trying to take the same approach as what you describe; glean a complete understanding of some problem based on “one or two” printfs, rapidly devolve into “three or four” or “a few more” until the cost has outweighed the benefit compared to just watching the problem happen in the debugger.

    Since I work mostly addressing issues with the products of other people’s endeavours, it will never be the case that I spend more time writing than debugging … as is the norm for our industry sadly =;-(

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: