, stack corruption. Or at least it looks like stack corruption. Someone's scrawling on memory, it doesn't always happen the same way, and you're able to UseTracing
to rule out noxious thread interactions. When you AskTheCode
it doesn't happen the same way.
Chop out the first half of your program. Do things still screw up? If so, the problem must be in the second half. Otherwise it's likely in the first. Verify that. Now take the half where you know the problem lies and chop out half of it. Repeat until you say AhHa
, or you discover an EnvironmentProblem
. -- PeterMerel
Remember that the BinaryChop
is one of the least efficient
debugging tricks you have in your bag. While it will almost always converge on a solution, regardless of environmental problems, it will do so slowly, at a high cost in time and effort. BinaryChop
is a "technique of last resort" - to be used after other appropriate techniques fail.
I think that's much too strong. BinaryChop can be time-consuming if pursued as a matter of course, but often one or two iterations of it can be combined with the rest of the DebuggingPatternLanguage to shorten the time taken. Debugging is helped by controlled experiments - show me a positive before a negative - and a little BinaryChop can often get you that faster.
In terms of efficiency (and only efficiency), BinaryChop
is to CodeUnitTestFirst
, as BinarySearch
is to HashTable
. I.e. O(log n) vs. O(1). BinaryChop
is definitely more efficient on a large scale than linear debugging methods such as reading the code or stepping through the debugger, although once you have narrowed the problem area, stepping through the debugger can be better than continuing with BinaryChop
The two parts don't have to have equal size or complexity. You should aim to get the same probability of error in each one. -- DaveHarris
If you know
a large portion of the program is correct, then this can reduce to SpikeSolution
. Forget all the mundane stuff; just write a small test program involving the new library/algorithm/language feature that's the SimplestThingThatCouldPossiblyWork
(or not work). I use this often when playing around with HaskellLanguage
. -- JonathanTang
POD is good for doing this since Perl doesn't have block comments.
=head1 Here's some cruddy code to switch off
$foo = 73;
is also the method you used to have to use on MacOsClassic
to pin down a misbehaving Extension or Control Panel that was causing crashes or weird behavior. -- EarleMartin
was the only technique available in my most HeroicDebugging
performance. -- JohnFarrell
(Description moved to HeroicDebugging page.)
Vaguely related to AbstractionChop