CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 06, 2017 at 02:23:59PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 6/6/17 12:39 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Tue, Jun 06, 2017 at 02:03:46AM +0000, jmh530 via Digitalmars-d wrote:
> > > On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
> > > > 
> > > > Time to find this: roughly 2 weeks.
> > > > 
> > > 
> > > Damn. That's some commitment.
> > 
> > 2 weeks is not bad for subtle bugs in complex code like this one. In
> > my day job I've seen bugs that took 2 *months* to figure out. One of
> > them involved a rare race condition that can only be reproduced
> > under very specific circumstances, and it took a long time and a lot
> > of guesswork before a coworker and myself discovered the exact
> > combination that triggered the bug, thereby leading to the subtle
> > problem in a piece of code that looked perfectly innocuous before
> > then.
> 
> Oh, I've had those before. I had a race condition that reproduced
> *randomly* and usually took about 2 weeks to happen, and that's by
> pounding it non-stop. The result was deadlock. Any debugging after the
> fact resulted in no clues.
> 
> Only way I solved it was to print out state as it was going, so I
> could see what happened when the state went bad. I think it took at
> least 2 cycles to find it.
> 
> This kind of stuff makes you appreciate how important avoiding race
> conditions and memory corruption is.
[...]

Yeah, race conditions and memory corruption / pointer bugs are the worst
to track down.  Since the codebase I deal with is in C, there are plenty
of opportunities for slip-ups that lead to pointer bugs.  And the worst
of them are dangling pointers... you write to them, and there's no SEGV
because they point to valid memory, but that memory has been allocated
to something else now.  By the time the corruption manifests itself,
you're already long, long past the original buggy code, usually in some
completely-innocent code that you can stare at for weeks or months and
not find a single flaw.  Meanwhile the original bug randomly corrupts
different things depending on who gets the memory pointed to by the bad
pointer, making it almost impossible to reproduce. Even after you
reproduce it, you've no idea how to trace it to the original cause,
because you're long past where it happened.  And it's almost impossible
to narrow it down, because reducing the test case may make the bad
pointer corrupt something else that you don't see, so you don't know if
the bug is still happening or not.

Things like this make you *really* appreciate D features like bounds
checking and the oft-maligned but life-saving GC.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG