Ah, yes, the instability of fake fixes to compiler bugs. I recall a friend of mine once had a bit of C code that would compile and run correctly only if debugging was enabled. His fix, to get it to run with full optimizations without segfauting was what he referred to as "the God code": int god = 1; To this day no one knows why that did anything at all, but at some point the compiler bug was fixed without anyone filing this bug that we know of.
That's a classic symptom (and "fix") for an array that was {over}/{under}run by one (or some small number of) element(s): the extra allocated space on the stack may have prevented it walking into unallocated memory (and segfaulting).
Now, if he'd run it under valgrind and it showed no problems of that sort, and it still segfaulted...
My understanding is that it was reversed from that, where with stack canaries and debug tracing nothing odd was happening, but when things are run without defenses it _stops_ working, instead of starting to work because you're paying less attention. That was why it was so odd -- obviously the array overrunning (or passing (void*) &local_var into subroutines where it's cast to a different type, etc) would be a pretty obvious candidate.
