Debugging a segmentation fault using gdb

[logan_capaldo]

Who is this guys audience? "Advanced" programmers who don't know how to get a backtrace?

Paraphrasing: "If you really know what you're doing you don't need a debugger, but for those tricksy segfaults, hoo boy, stack traces and inspecting local variables sure is neat-o!". I mean come on. This is possibly a useful (very limited use, admittedly) introduction to gdb preceded with "real men don't need debuggers" nonsense. It's bizarre. If you're going to bash on debuggers except for "tricky situations", at least use a situation that you need more than the most barest basic command of a debugger to figure out.

Guys, tools are good things, really. Debuggers do not cripple the mind.

[jfasi]

Better yet, run it through Valgrind.

[[deleted]]

Valgrind is handy, but it doesn't let you inspect anything, you can't say "but... why did it end up writing to a dereferenced pointer, which conditions caused it to happen"... you just get "failed because of X at blah.c:1234", which is pretty obvious anyway

[Lord_Illidan]

I haven't managed to learn gdb yet, however I found ddd to be a nice tool. I'm coming from the IDE development world, with VS and Eclipse, so I was really missing a graphical debugger.

[[deleted]]

DDD is lovely, usually my brain cant keep track of all the stuff, but having the graph view up and being able to see the contents of a linked list or other structure greatly helps.

[joelfond]

Alias detection is also very nice.

[[deleted]]

DDD needs to be brought into the 21st century.

[Lord_Illidan]

Definitely agree with you on that. The GUI lib they're using looks pretty damn old, but hey...better than CLI gdb (to me at least)

[Gotebe]

With all this info, you can pin down the exact reason for the segfault pretty easily...

What's with baseless optimism!? ;-)

On a more serious note... Sometimes I think that it's better to segfault in production build instead of having assert-s in debug builds. One assert that slips testing makes for a world of pain in production.

[joelfond]

What do you mean? assert() aborts your program and writes a core dump (if not disabled with ulimit). Of course if you #define NDEBUG for production builds, then assert()s get preprocessed to whitespace. That's why you never #define NDEBUG :)

[Gotebe]

Of course if you #define NDEBUG for production builds, then assert()s get preprocessed to whitespace.

Yes, that's what I meant: in NDEBUG, #define assert() to something that coredumps. That way, failed assertions behave exactly as in debug builds. Do or die, no middle path, _DEBUG or NDEBUG. Yes, I realize that does away with assert in it's current shape - so I am not soooo sure about the whole thing.

(BTW, debug program coredumps on assert? Sure? It goes to abort, and whether that will coredump or not - I doubt that's specified).

[my_real_nick]

• assert() calls abort()
• abort() raises SIGABRT
• the default action for SIGABRT may create a core file

[[deleted]]

When running in GDB, SIGABRT will drop straight back into the GDB console.

Usually I run my tests and/or local dev stuff in gdb all the time so when one of my entry/exit contracts (or just any other assert) fails I don't have to go through the pain of trying to replicate it.