# $Id: BUGS,v 1.31 2007-01-12 21:06:22 martin Exp $ Gullydeckel2 Bug List: 2.15pl6: If Gully fails low, it reverts to the 'saved move' (move that failed low) if time runs out during re-search. That is fine. However, I am sure not whether it works well if Gully transposes from ponder to search. Analysis has strange output then (shows really bad scores if we re-search with open window.) Move ordering is the way to go. 2.15pl3: sz.fen: Mate in 5 Problem - Gully took 13(!) plies to find the mate, but reverted back to a mate in 6 and a mate in 7 later on. Hashtables and null move switched off. fen: 8/1K1R4/1p6/1N6/kPB5/P7/3P4/8 w - - 0 0; bm Bd5!; sz1.fen: null move caused the mate to be hidden. Check the test log - the mate pv is always the last line seen at this depth (search control). Revisit when search is understood and documented. 2.15pl1: Revisit Ra7 effect - put this or similar position in test position. 2.14pl5: parser does not tolerate misformatted epd-testsuites very well. 2.14pl2: Reimplementation of the NEW command broke compatibility with Xboard 3.5: Gully does not detect that it is in xboard mode: time gets not updated if it is Gullys move and Xboard hangs after sending Gully a "post" command. (Workaround is to use -x switch to force xboard mode.) 2.14.pl0: Review hash tables: Is there any aging algorithm implemented? In other words: Are deep scores from old plies sitting there till the end of the game? 2.13.pl7: if we got the NEW command while searching or looking up book up moves, we must not execute our search result. return and let normal input handling take of handling the reset. (we don't check input while browsing the book, but anyway). Unfortunately, Gully does not check for input when it is SEARCHING. (only while PONDERING). So, a reset problem with xboard persists: If Gully is reset via NEW, it may emit a move valid in the start position which will be executed by XBoard. Revisit this when "move now" is implemented. 2.13pl3: Reported by Dann Corbit: a) It is safe to stop the search if a mate in n is found and we have searched 2*n plies. It does not get any better. b) We should never fail low in the next ply after we found a mate. (due to null move, see wac.001, IMCP.11 for 2.15pl1) 2.11: * new move ordering strategy: killers might overlap with captures, in which case they dont get the correct bonus (check order.c and search.c) ?? 2.9: * For Maresch test suite: omitting semicolon at end of epd record lead to crashes also, omitting a move after bm tag resulted in bugs (partially fixed, needs tests) 2.7beta * timing: Gully uses systemtime but doesnt realize that in matchmode it gets only half of the processor, so it uses way more time than it should. * Gully2 cannot use the plies_since_last_capture_or_pawn_move which is optional in epd record. Possible solution: don't check for move_flags[0].irreversible_cnt > 99, but for > variable (with variable being 99 most of the time) ========================================================================== FIXED BUGS: 2.15pl8: For Win32 on the dual Xeon: Gully sometimes loses on time in fast games ( 2 0 vs GNU). Check time management code. I think this fixed in 2.16pl1. (Tests and fixes by Olivier and Andrew) 2.15pl8: set stdin and stdout for Win32 to _IONBUF (_IOLBUF fails at least for stdin). 2.15pl5: eval bug fixed: evaluates 2Q vs Q as -11.xx score (due to wrong pawn hash initialization for ptable[0]). 2,15pl3: pondering problem (reported by Leo Dijskman): Fixed explicitly changing buffering mode for input pipe (from winboard) via setvbuf. I guess line-buffered is OK. (2.15pl8: It is not.) 2.15pl3: specifying --null on the command line has no effect; phase() always decides itself. FIXED. (phase() keeps initial state in a static variable) 2.15pl3: It was possible to start Gully with --transref 0 and switching hash table usage on with 'hash' later on, resulting in a core dump. Fixed. 2.15pl1: book generation (book_up()): Our generated move did not match moves like R1d2, N4f3 and so on. Those move are currently rejected by the book building process. Fixed (parser bug) * when running the starting position, gully has a bad PV: 8. 0.00 7.11 173844 b1c3 b8c6 g1f3 b8c6 c3d5 g8f6 (Nc6 double) Fix: cut_pv() if null_move results in alpha < score < beta. * Gully2 doesn't correctly handle fail-low situations. It will "over-react * and pass an very bad move back. (just some move it got during the * re-search with open window. This move will have a good score (the one from * the previous ply) Fix: (by saving last move resulting from last finished search (not aborted)) - see iterate.c * after adding pondering (15.3.97) Gully had "illegal move:" statements on GICS xboard (but didnt lose a game due to it???) and had also "hoppla! TT move not found" (with a sane looking move and also at low depth) This is perhaps due to an interface bug and not a search bug. * Interface bug: For some reason Gully did fgets while pondering (a la crafty), but didnt get the move after time, otim. Fix: Both were seemingly solved when keeping the number of chars actually waiting (pending_chars) * when using setup, afterwards level, gully2 will still use the constant 10sec time allocation. Not so when under xboard. Fix: setup command is different from edit; now it saves the old gameTime too. * segmentation fault when nearing the 50 move limit in KB vs. K (last depth was 28), probably due to too deep search. Fix: repetition_arrays too small (25+MAX_DEPTH/2) is wrong, (50+MAX_DEPTH/2) correct. Also History array site is now MAX_SEARCH_DEPTH (e.g. down to to ply 70) * see: in W: Pg5,Bh4 B: Pf6,Be7 the bishops are not recognized as indirect attackers(due to the correct assumption that this is at least a trade, but this is not enough - in hung piece detection only winners are looked at) Fix: In 2.9 - improved implementation of fill_see_array takes care of this (also see is more exact overall) * For Maresch test suite: node counts differ for compilation w/ and w/o debugging support. Fix: reset transref and killer table when setting up a new position. * Gully 2.11 would still call pick() in quies, although there is no content (keys not set by generate_captures anymore) FIXED. 2.12pl3 Adding endgame evaluation and king (+ to a minor extend) rook eval) makes all the difference in the tests. There are no bugs relating to the extended material count. But the king eval has a surprisingly bad influence in (almost?) all test suites. Going from evaluate.c 1.17 to 1.18 caused a drastic drop *not* in nps, but in plies searched. E.g. bk.08 (9 complete in 30s) loses 2 plies! Also bk.9 (6), bk.10 (6), bk.11 (6), bk.12(6) - very quiet pos with one only move Bf5) and many others are plain slow. see "tkdiff -r 1.17 -r 1.18 evaluate.c" **************** Explanation: The reason was introducing king safety. Introducing the splitted material score causes about 8-9% overhead in nps (node counts being equal). 2.13pl2: attacks.c:fill_see_array() PieceBits[GET_PIECE(*BOARD[src])]) did lookups beyond the array bounds (found by D. Corbit) FIXED: (forgot occurence of pawns, it is now tested for pawns explicitly. M. Borriss, 29.4.2000) 2.13pl0: book.c borrowed from crafty. it needs a function which gets a text string and reads all kinds of input (abbreviated *plus* 0-0 O-O etc.) DONE. 2.13pl5: did not check return value of fgets in input.c broke in fast games because of unhandled error condition: interrupted system call (yes, it really happens (xboard did send SIGINT while gully2 did a read(stdin) via fgets. FIXED. (in 2.13pl6) 2.13pl3: "book" command if there was no book given: white:book Book off. Using: , size 0 (about -8192 positions) (still in 2.13pl4: book on should be rejected if we dont have a book file; or it should be loaded then) FIXED. (in 2.13pl4) 2.13pl3: "new" command does not reset the game; instead it just configures gully for working with xboard. FIXED (in 2.13pl5) 2.8 and earlier: *MAX_MOVE_ARRAY 1000 was not sufficient in some cases (one yazdac position this limit was overstepped at about 10 min on PPro in ply 27) It is 1800 now which may also not be sufficient anymore. Try to find out maximum use in test suite.