The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.

Segfault is only best-case scenario if it happens at the location with the bug.

It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.

Agreed.

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?

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

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.

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

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 :-)

Depends, if it happens in prod, you are **

If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.

Fair enough.

Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.

It has been many years since I spent "hours debugging" a segfault. But I use C++, not C.

(That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)

I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.

This is quite rare in C++ since C++11.

Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters.

Scala has the same problem. Stop writing your own DSLs!

> Stop writing your own DSLs!

100% disagree. Writing custom DSLs is how you get the best programs.