OhOh, 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. 

'''Therefore,'''

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

-----

'''However,'''

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;
 do_something_stupid($foo);
 =cut

The BinaryChop 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
----
BinaryChop was the only technique available in my most HeroicDebugging performance. -- JohnFarrell

''(Description moved to HeroicDebugging page.)''
----
See DivideAndConquer, OneLineAtaTime

Vaguely related to AbstractionChop.
----
CategoryDebugging