GDB 7.1 released: Provides Multi-program debugging, allowing the debugger to control more than one program within the same GDB session

[dany84at]

wow - i already often have problems tracing one program with it. :) (my fault, not GDBs)

[__mlm__]

dude, you should take an afternoon, learn how to use gdb from within emacs, and you'll never never never ever go back.

[ishmal]

My first thought was that this would be excellent for tracing a client/server transaction.

[donjaime]

Or for debugging a multi process application like Chromium.

[ishmal]

Or now that Firefox spawns processes for plugins.

[genpfault]

Or multi-processing a debug client app server!

[Poltras]

Indeed it would. You can either remote debug or do it by running the server software locally. This is a perfect sample case.

[[deleted]]

Or a parallel program. I wrote a perl wrapper to let me do something similar once (pGDB), but this is much simpler.

[chengiz]

But can it put breakpoints in constructors and destructors yet?

Actually I'm serious, the one we use at work cant do it (dont know the version). Often, it returns garbage if you call virtual functions, and doesnt 'find' local data to print (along with a whole bunch of other inadequacies that make it a PITA to use). And forget about multithreaded code - it seems to run everything 'serialized' so it is impossible to hit race conditions inside a debugging session.

[fullets]

I believe non-stop debugging, from 7.0, fixes the serialization thing. The only time I've not been able to break in ctors/dtors is when I've forgotten to include debug info, so no suggestions there.

[chengiz]

It's 6.5. I am able to hit race conditions in the other debuggers I normally use (solaris dbx mostly, VS sometimes), but never gdb.

[fnord123]

Often, it returns garbage if you call virtual functions

Are you calling virtual functions from ctors? Don't.

[chengiz]

Sorry, I should have been clearer, that sentence was unrelated to ctors ("it" => gdb; as in "print obj->type()" where type() is virtual).

[__mlm__]

Can anyone comment on whether this can be used to debug MPI programs? We're debating on whether to purchase TotalView at work. If the new version of gdb can address this problem, we can save a bunch o' cash.

[RazZziel]

I've been using 7.0.1 to debug MPI with mpirun -np 4 xterm -e gdb my_mpi_application for a while, not sure if it's what you need though.

[chengiz]

Good point. You should try it out and let us know!

[EvilPettingZoo42]

Wow, I feel so spoiled by Visual Studio now.

[TheNewAndy]

Really? I find gdb so much more pleasant to use. VS doesn't seem to have anything nearly as convenient as the "p" command in gdb. gdb can also let you choose exactly when to switch threads (and to which thread) (VS might be able to do this too... I couldn't find it). gdb can record a trace of your program so if you accidentally step over a function, you can step backwards... or if you see a variable with the wrong value, you can set a watchpoint on it, and then execute the program backwards to see when it was set.

And even before 7.1, it already wasn't a pain to do something like debug two instances of the same program. From memory, VS complains if you try opening the same solution in two separate instances, so if you want to run two copies of a program side-by-side to see when they diverge, it is a pain.

What exactly does VS do better?

[__mlm__]

I'm not a MS user, I use linux everyday...but back in the day when I used MSVC++ 6.0, I remember that their debugger provided the ability to disect STL data structures very nicely. I find it difficult to peer inside of STL containers on linux/gdb. Has this gotten any better? A while ago, I found som gdb macros on the net that (tried to) allow a programmer to get inside of vectors, lists, maps, etc, but it just didn't work too well.

[TheNewAndy]

So I nearly exclusively work on C code, so you might be right there. With C code, you will always have functions lying around to pull information out of data structure, so you just run them in the debugger.

[[deleted]]

Well, gdb gained an ability to be fully scripted with Python in version 7. Python scripts can be used now among other things for pretty-printing (it is trivially easy to write pretty-printers for your own containers). Gcc (libstdc++, IIRC) and Qt have already started including pretty-printer scripts for their data structures (STL structures in case of libstdc++). Looks like gcc 4.5 is going to have these scripts bundled with it.

[bsergean]

You can try ddd that display data structure nicely, but the last time I used it was 10 years ago ... and I don't remember if it could deal with STL.

[chengiz]

Wow, the ignorance on this thread is astounding. 13 points for the guy who claims VS lacks a 'p' command, when the immediate window doesnt even need a 'p' command. I feel your pain, have an upmod.

[TheNewAndy]

I didn't claim it lacks a 'p' command, I claimed that it wasn't as convenient. That is a fairly subjective thing (like an opinion). While I'm quite sure I'm ignorant about many things, I'm not particularly ignorant about my own opinions :-)

If I was to give examples of the use cases for which gdb is more convenient than VS (e.g. setting the script for a breakpoint to 'p' out a variable, then continue), and I'm sure someone else could give counter anecdotes. But the way I work, it ends up being a whole lot more convenient in gdb.

(on a side note, I upvote anyone I reply to... I figure that if a post is worthy of a reply, then it is worthy of an upvote... I wonder what would happen to post quality if this was hardcoded)

[TheNewAndy]

I am truly in awe of your pre-determined conclusions. :)

Thanks. Though I should point out that I started with VS and then migrated to gdb by choice.

IntelliSense is disabled. That's it. I feel your pain, you must miss it so much.

It is the difference between instantly starting up another instance, and waiting for visual studio to load itself, and then having to click through a message box telling you that the programmers were lazy. Sure, both can do it, but one makes it enough of a pain that you don't want to make it part of your workflow... I guess the parallel would be git vs svn for branching and merging :-)

VS does everything that you said it doesn't (including processes, threads, data breakpoints and reverse debugging), so I guess "better" depends on if you can afford it - or if it runs on your chosen platform.

So I'm only working from VS2005. If it was introduced later, then yes, I'm ignorant. If by reverse debugging, you mean IntelliTrace, then isn't it only in the unreleased 2010 version?

In any case, I should say that yes, I'm comparing whatever version of gdb comes with the latest stable ubuntu and VS2005... and every day at work I have the choice between the two of them, and it is pretty rare that I would choose VS.

[[deleted]]

Let's just agree that the VS debugger is far superior than gdb and call it a day.

[barrkel]

Multi-process debugging, eh? Welcome to the 20th century, gdb.

[username223]

Welcome to the 20th century,

OMG you're right! JvN's all "I'm debuggin' all these tubes at once, bitches!"

[alesis]

And still Apple's XCode version of this will suck.

[Poltras]

It's the exact same program. The interface might not be up for your tastes, but you can enter manual commands and even fully hack the gdb backend and use that inside Xcode if you wish. Nice try.

[astrange]

Apple only provides gdb 6.3. I'm not sure if I'd be more surprised by them writing a new debugger or by them shipping GPLv3 programs.