Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And even without that when you're faced with a bug caused by a large input of some kind it's often easier to dump a bunch of data and look for what doesn't fit.

I've had two Heisenbugs, although no threading involved:

1) Long ago, interface library for going from protected mode to real mode in I believe it was Borland Pascal (I can't recall for sure where this was relative to the name change.) Step through at the assembly level, it worked. Anything else it might work but that was unlikely. The only outcomes were correct or segment error, it never returned a wrong answer. Culprit: Apparently nobody used the code. The whole file was riddled with real mode pointers declared as pointers. Oops, when asked to copy a pointer the compiler emitted code that loaded it into a segment:offset pair and then stored it. If the segment part happened to be valid, fine. If it wasn't a valid segment, boom. The debugger apparently did not actually execute a single step, it emulated it--except for not failing on an invalid segment register value. In any other case the attempt to dereference it would have blown anyway, but this wasn't being dereferenced.

2) Pretty recently, C#. I had a bunch of lazy-initialize data structures--and one code path that checked for the presence of data without triggering the initialization. But the debugger evaluated everything for display purposes, triggering the initializer. There is a way to tell the debugger to keep it's hands off but I hadn't heard of it until I hit it.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: