[Kon-Peki]

My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities.

I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?

[yakubin]

In cases when I have a working visual debugger, I agree, it's fun. Without one, it's not fun.

[Kon-Peki]

Oh yes, for sure. Visual debuggers make things so much easier! It might be worth pointing out that visual debuggers have been around for well over 30 years at this point.

[jcelerier]

when do you not have one ? as soon as you have a mere hint of gdb / gdbserver possible you can debug in a GUI such as Qt Creator's

[klodolph]

A couple situations.

Sometimes you can end up in a pickle because the embedded system you’re working with just doesn’t have a good debugger available, or it may be cumbersome to set up.

Sometimes the segfault happens in a production environment and you just can’t hook up a visual debugger to the ten different instances of the server you’re running.

I agree that a segfault is a fun error to try and diagnose because it really exercises your gray matter. But it’s not my job to diagnose segfaults, it’s my job to keep the service running up to some certain standard, and if I find myself diagnosing lots of segfaults, there is usually something else I could be doing involving instrumentation or testing to address those defects which is more boring but more productive :-)