3 ms·
These 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 se
by rfnslyr 13y ago
These 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.