7 ms·
If you have never taken 24 hours to debug a segfault, you haven't done enough C/C++ programming. E.g. a rare race condition causes some memory to be freed whil
by humbledrone 13y ago
If you have never taken 24 hours to debug a segfault, you haven't done enough C/C++ programming.
E.g. a rare race condition causes some memory to be freed while there's still a live pointer to it, but THAT doesn't cause a segfault immediately because the memory is immediately reused for some other data structure (in a different thread), so when the dangling pointer is accessed it points to allocated memory that's being used for some other purpose. Some field in the data structure the dangling pointer references is mutated, and then finally in another thread that same memory is accessed via a different pointer (the one that was recently allocated) and part of it is treated as a pointer, and dereferencing THAT causes a segfault.
(Oh and by the way, in real life things can get much more complicated than this before the program blows up with a segfault. In fact, you're lucky if there's a segfault, instead of finding out months down the road that your data has been subtly wrong the whole time.)
Ultimately the solution to this is some iterative combination of swapping in a guarded malloc, then trying things in Valgrind, then trying various Valgrind options, then setting some hardware watchpoints in gdb, then finding that the race condition disappears in the debugger, then adding log statements all over the place, then statically analyzing the code for hours while pulling your hair out, then finally by accident noticing that padding the first data structure with an extra field makes the problem go away, then setting the right hardware watchpoint that actually helps, etc, etc, then piecing together a real story for what's happening, and ultimately making a 2-line fix.
If you think you're somehow "above" this kind of horrible drudgery, and that your immense programming skill will let you avoid it forever, then you are just not very experienced (or you're not working on hard problems).
- rfnslyr 13y agoThese things are true. Things do quickly get complicated when you're trying to replicate race conditions. What you described, though, is not trying to "fix a segfault" it's trying to "fix a race condition" where the fault is just a symptom. In the example in your OP there was none of that. Even assuming what he meant was that he accidentally mutated a pointer he passed by reference instead of value which caused problems after he returned and things fell out of scope or were freed, you could debug that in 5 minutes just by setting a watch breakpoint on the pointer to see where it was last changed before the errant access. An hour, tops, if that didn't occur to you to begin with. Tracking down multi-threaded memory corruption is tough, but those bugs are going to be rare. Threading is a tough problem to begin with, but it's certainly not a fault of C/C++. And whatever this guy was describing should not have taken 'hundreds of test cases and over 24 hours'.
- humbledrone 13y agoWhy do you say "should not have taken?" Given the fact that he was a student at the time, learning C++, I think it's perfectly understandable that he ran into a "bang your head against the wall" type problem. Maybe it was his first real segfault debugging session. I doubt you solved your first real segfault in 5 minutes. Sure, I'd expect someone with a couple years' experience to be able to debug a simple segfault relatively quickly. But the only reason they'd be able to debug it quickly is because they've _painstakingly done it before_, and can draw from that experience.