Debugging

Kriecht es, fliegt es mit Gebrumm ||~  ||^   || toc =x86 Breakpoints= 8086, x86 and x86-64 have the [|int 3] one byte software [|interrupt] instruction with opcode 0xCC, which might be explicitly used, or implicitly in assertions. This instruction is also used, when setting a breakpoint from a debugger, where current opcode is (temporarily) replaced by the //int 3// opcode (0xCC), which when executed calls a special interrupt routine of the debugger or runtime system.
 * Home * Programming * Debugging**
 * [[image:mm-05-12.gif width="289" height="179" link="http://www.wilhelm-busch-seiten.de/werke/maxundmoritz/streich5.html"]] ||~  || **Debugging** is a process of finding and reducing bugs in a computer program. A [|debugger], usually in software, allows to execute the program (debugee) under its control, to set [|breakpoints], let the user step to single lines of his source or machine code, to inspect variables, memory and processor registers. Processors often provide special instructions for the purpose of debugging. ||
 * Hin und her und rundherum

Breakpoint opcode may be inserted inside the code at compile time, for instance with x86 inline assembly or compiler intrinsic like //DebugBreak// : code __asm int 3 code =Compiler Support= Various compiler allow a special Debug build, which disables optimizations, default initialization of otherwise not initialized variables or memory, and/or enable runtime checking, like [|bounds checking] of array access. Various [|integrated development environments] (IDE) provide an integrated debugger.  =Debugging the Search= A recursive search is quite hard to debug. Therefor chess programs may provide debug routines to use a sequence of certain moves or a zobrist key as a precondition to break the search if they occur. Here are Tord Romstad's suggestions in a reply to Patrice Duhamel :
 * Extend the UCI/XBoard command set with a few commands of your own for use in debugging. In particular, it is useful to have a command for looking up the current position in the hash table and printing the information (score, score type, best move, etc). to the standard output. You can use this to browse the search tree after a search is finished. When you want to know why the program discarded some move, you can make the move and inspect the hash table entry for the corresponding position to find the score and refutation. I've found this to be a very valuable debugging technique, and even have a simple GUI app for browsing the tree (the GUI app communicates with the engine through pipes connected to the standard input and output).
 * The technique above can be further enhanced by including lots of additional information in the hash table when debugging the program. I sometimes store complete move lists with information about extension, reduction and pruning decisions for each move in every transposition table entry. Of course this makes each entry huge and greatly slows down the search, but it can be useful when chasing bugs or looking for ways to make the search more efficient.
 * Implement an MTD(f) search, even if you intend to use PVS. MTD(f) is great for debugging the hash table; all sorts of obscure bugs which are very tricky to find in PVS or other conventional searches suddenly become easy to spot.
 * Whenever you add some non-trivial new function to your program, try to write two versions: One which is very slow and stupid, but almost certainly correct, and one which is highly optimized. Verify on a huge number of positions that they give the same results. Remove the slow version only when you feel 100% sure that the fast version is correct.
 * Always make symmetry tests when you add a new term to your evaluation function.
 * Run through a simple tactical test like WAC at 5 seconds/move every time you change something important in your search. Don't try to optimize the results, but just make sure that the score doesn't suddenly drop dramatically.
 * Check the quality of your move ordering by measuring how often a beta cutoff occurs on the first move, and the frequencies with which the 1st, 2nd, 3rd, ... move turns out to be best at PV nodes.

=See also=
 * Bibob
 * Engine Testing
 * Famous Bugs
 * InBetween
 * Logging
 * Spracklens debugging with Apple II ICE

=Publications=
 * Zhonghua Yang, Tony Marsland (**1992**). //Global Snapshots for Distributed Debugging//. [|ICCI 1992], pp. 436-440
 * Zhonghua Yang, Tony Marsland (**1993**). //Distributed Debugging in the Large//. [|pdf]
 * Chrilly Donninger (**1999**). //Computer machen keine Fehler//. CSS 2/99, [|pdf] (German)
 * Yngvi Björnsson and Jónheiður Ísleifsdóttir (**2006**). //Tools for debugging large game trees//. [|11th Game Programming Workshop], [|Hakone], [|Japan] » Search Tree
 * Jónheiður Ísleifsdóttir (**2007**). //GTQL: A Query Language for Game Trees//. M.Sc. thesis, [|Reykjavík University], [|pdf]
 * Jónheiður Ísleifsdóttir, Yngvi Björnsson. (**2008**). //[|GTQ: A Language and Tool for Game-Tree Analysis]//. CG 2008, [|pdf]

=Forum Posts=

2000 ...

 * [|Debug Help] by Georg von Zimmermann, CCC, September 16, 2000
 * [|Winboard.debug] by David Rasmussen, CCC, December 07, 2002 » WinBoard
 * [|bugs, Bugs and BUGS!] by milix, CCC, May 27, 2004
 * [|Q. Why might node count differ between DEBUG and RELEASE] by David B. Weller, CCC, December 13, 2004

2005 ...
> [|Re: Testing and debugging chess engines] by Tord Romstad, Winboard Forum, December 05, 2006
 * [|General Tips and Tricks for debugging a search] by Eric Oldre, CCC, June 15, 2005
 * [|Testing and debugging chess engines] by Patrice Duhamel, Winboard Forum, December 03, 2006

2010 ...

 * [|Debugging regression tests] by Onno Garms, CCC, June 16, 2011
 * [|DrMemory: memory debugger tool for Windows (and Linux)] by Martin Sedlak, CCC, January 22, 2013 » Memory

2015 ...

 * [|OT: Finding the Line of the Assert Fail?] by Steve Maughan, CCC, March 07, 2015 » Maverick
 * [|Best way to debug perft?] by Meni Rosenfeld, CCC, January 25, 2016 » Perft
 * [| Help with Debugging My Chess Engine] by Pranav Deshpande, CCC, September 28, 2016
 * [|Help with Debugging My Chess Engine - 2] by Pranav Deshpande, CCC, September 30, 2016
 * [|How to go about chasing a bug like this?] by Colin Jenkins, CCC, February 09, 2017
 * [|How to find SMP bugs ?] by Lucas Braesch, CCC, March 15, 2017 » Lazy SMP
 * [|assert] by Folkert van Heusden, CCC, November 13, 2017
 * [|How do I debug cutechess-cli engine input/output?] by Daniel Dugovic, CCC, December 25, 2017 » Cutechess-cli
 * [|Debugging UCI engine] by Cadel Watson, CCC, January 19, 2018 » InBetween, UCI Engines

=External Links= > [|Brian W. Kernighan], [|Rob Pike] (**1999**). //[|The Practice of Programming]//. [|Addison-Wesley], ISBN: ISBN 0-201-61586-X
 * [|Debugging from Wikipedia]
 * [|Debugger from Wikipedia]
 * [|Assertion (software development) from Wikipedia]
 * [|Regression testing from Wikipedia]
 * [|GDB: The GNU Project Debugger]
 * [|gdb + eclipse - SWiK]
 * [|IDA Pro Disassembler - multi-processor, windows hosted disassembler and debugger]
 * [|SoftICE from Wikipedia]
 * [|CHESS - Microsoft Research] a tool for finding and reproducing [|Heisenbugs] in concurrent programs.
 * [|From Chapter 5, Debugging] excerpt from Chapter 5 of
 * [|Electric Fence (Memory Debugger) from Wikipedia] » Memory

=References= =What links here?= include component="backlinks" page="Debugging" limit="80"
 * Up one Level**