Is debugging in Project Builder really this bad?

[KenD]

Ok, so I have spent the last two days getting more and more frustrated about the whole PB thing to the point that I will try to do my Cocoa/C++ project in CW instead.

It's mainly the debugger that drives me nuts. Viewing variables is a pain and stepping through code is no better. Most of the time the stop point is on lines with no code at all so trying to figure out what's going on is a guess work at best. Trying to view a buffer with a text string is next to impossible.

Is it really this bad or am I possible doing something totally wrong? Having to spend most of the time fighting the tools something is wrong somewhere.
I finally set up a CW project with the same stuff and after some minor problems the compiler complained about I could debug and see what was actually going on.

I want to like PB but in it's current state I just can't. Is debugging this bad in PB?

KenD

[Zoldar256]

Yes, PB's gdb interface is pretty lacking.
I really dislike Metrowerk's debugger also, sometimes it is inacurate about reflecting what is going on in the code. While just anouying most of the times, other times it can lead to real problems. But it is certainly better than PB's gdb interface.

BUT Remember, PB is just providing a front end to gdb. So if you can find a really nice *nix GDB front end, chances are you can use that to debug your applications. For isntance, I have used DDD many times to debug stuff. Or GVD (GNU visual debugger).

Though I am unsure of each one's ability to deal with objective-C. Especially DDD with it's fancy data-structure graph display. Another thing to be wary of is that these probably won't integrate well with PB. And both require XWindows to work.

[OneSadCookie]

Make sure you turn off optimizations when debugging. If you don't, the line indicator will be hopelessly wrong.

It is just a front-end for GDB, so you can always get the GDB console and type GDB commands.

[Mark Levin]

There are 2 reasons the debugger would stop on a line with no code on it:


The compiler is agrressively optimizing and the step command is trying to find the C to go with the current assembler instructions. Build the debug target (or any target that uses -O0).
Your source and executable are out of synch. Switch to using the "build and debug" command instead of just "debug" (which launches the executable without checking if it's up-to-date).


I too thought PB's debugger sucked, but spending a few minutes learning GBD's commands has made it a lot better.

Heh... that took too long to write :p

[KenD]

Thanks for the tips. I should have thought about the optimization level. It was set to -Os.
Using the command line is probably even worse to me compared to what I have encountered so far so I don't think I will try that.

CW uses gdb also and it sure has a much better front end IMO. I can't say I have noticed any problems there really.

I moved the project over to CW for now. I can always move back to PB (or Xcode) if it will be an improvement but currently I make better use of my time when I use CW.

The editor in PB is very buggy also and a big source of frustration. I understand you can use external editors but that just gives you other problems instead so I don't know if it would be any better.

KenD

[Fenris]

If you feel like chucking up a few dollars, get Big Nerd Ranch's Core Mac OS X Programming - the chapter on GDB is worth the price of the book alone...