Debugging for lazy chess programmers

Discussion of chess software programming and technical issues.

Moderator: Ras

abulmo
Posts: 151
Joined: Thu Nov 12, 2009 6:31 pm

Re: Debugging for lazy chess programmers

Post by abulmo »

A very useful debugging tool that as not be mentioned so far is valgrind (or any similar program). It is very good at detecting uninitialized data, out of bound memory accesses and memory leaks.
Richard
xmas79
Posts: 286
Joined: Mon Jun 03, 2013 7:05 pm
Location: Italy

Re: Debugging for lazy chess programmers

Post by xmas79 »

jdart wrote:assert is very useful...
Asserts are the way to go for bug hunting. For each line of code I write that accesses an array/matrix I put an assert just before to check index consistency. For each make/unmake I assert the board is ok, eg is self-consistent. Then I take also the statistical approach: two long-term self-play matches: one at 1 sec/move, and one at 30 sec/move, which will allow to catch any rare event (like a pv retrieved from hash hit is not related to the position, I just hit this now...) caused by search instability & co. My search speed in debug mode is between 15Knps and 100knps, and I get at most depth 6 in the opening/midgame (30sec/move), more in endgames.

Natale.
User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 4:27 pm

Re: Debugging for lazy chess programmers

Post by Don »

Henk wrote:Again I have been busy all day with debugging. This time there was a bug related to updating bit boards when capturing pieces of the same type (Rook x Rook, Pawn x Pawn etc)

So I expect there will be more of these tough bugs in my software. The problem with my latest bug is that is wasn't visible at the user level. It played normal chess. Only by accidence when I tried to optimize my q-search I encountered them.

Removing the bug did not make my program play better. So perhaps retuning (again and again) will be necessary.

To reduce bugs one may use:

- Perft
- Code inspection
- Test cases

I don't like writing test cases. What other methods are there for finding hidden bugs or the bugs you cannot find and you'll always overlook ?
Perft is is the best way to debug your move generator. Also try calling it with colors reversed and it should produce identical results. If there is a bug in perft you can use a divide feature such as in sharper which will give you move counts move by move.

I do most things twice when I'm writing new routines using a simple way that it less likely to have bugs and the the efficient complicated way and run them both to compare. You can test incremental zobrist hashing this way, just write a routine which caluclates the hash from scratch by scanning the board and then after every move see if it agrees with the incremental hash.

asserts can be extremely helpful too if you dont' miss an important case.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
rreagan
Posts: 102
Joined: Sun Sep 09, 2007 6:32 am

Re: Debugging for lazy chess programmers

Post by rreagan »

Henk wrote:Again I have been busy all day with debugging.

...

I don't like writing test cases.
Well, there's your problem. Learn to like either debugging or writing test cases. You can't avoid both.

I used to spend tons of time debugging. Now I write very defensive code, wrapped in classes, with asserts everywhere to verify that invariants remain protected. I haven't counted, but I would guess I have more unit testing code (test cases) than I have chess playing code. I'm sure my program isn't bug free, but it's a great feeling to know that every time the program runs it does many thousands of sanity checks automatically. I have two kinds of asserts, one that only runs in debug builds, and another that always runs the sanity checks for every class at startup. It's scary how often I make a change and break one of the test cases. If I didn't have all of those test cases, those bugs would pile up and I would never make any progress. With the test cases I at least have a fighting chance.