Author: Eric Oldre
Date: 12:28:55 06/16/05
Go up one level in this thread
On June 16, 2005 at 13:22:12, Dann Corbit wrote: >On June 16, 2005 at 12:09:57, Eric Oldre wrote: > >>On June 15, 2005 at 16:36:54, Eric Oldre wrote: >> >>> >>>I was wondering if anyone would like to volunteer any tricks they've >>>used to help find certain bugs in their search function. >>> >>>I think that the ideas of using perft for move generation and >>>reversing the board to find bugs in the evaluation have both >>>been really useful to me. I was wondering if anyone has used >>>techniques similar to these to help find search bugs. >>> >>>I understand that just because a engine can properly pass these >>>and other tests doesn't mean it's free of bugs. But they certainly >>>help detect at least some of them. >>> >>>I'm certain that there must be plenty of bugs in Latista's search >>>and I think it's time for me to work on discovering them. If >>>you don't have any automated tricks like above. Does anyone >>>have any general advise to help me spot some bugs? >>> >>>Eric Oldre >>> >>>PS. I have at various spots in my program tried to follow a similar >>>model of asserts as in fruit. I'm sure taking some time to >>>do this at more parts of my program would help. >> >>Thanks to everyone to has responsed so far. I've picked >>up quite a few ideas here that it will take me some time >>to implement! >> >>when using a ASSERT scheme similar to fruit's where >>it logs the file and line of the failed assertion, using >>__FILE__, and __LINE__. Is there any programatic way to >>access the call stack? > >Not portably. The standard also supplies a function name macro. Not every >compiler supports it yet. > >©ISO/IEC ISO/IEC 9899:1999 (E) >7.2 Diagnostics <assert.h> >1 The header <assert.h> defines the assert macro and refers to another macro, >NDEBUG which is not defined by <assert.h>. If NDEBUG is defined as a macro name >at the point in the source file where <assert.h> is included, the assert macro >is defined simply as >#define assert(ignore) ((void)0) >The assert macro is redefined according to the current state of NDEBUG each time >that <assert.h> is included. >2 The assert macro shall be implemented as a macro, not as an actual function. >If the macro definition is suppressed in order to access an actual function, the >behavior is undefined. >7.2.1 Program diagnostics >7.2.1.1 The assert macro >Synopsis >1 #include <assert.h> >void assert(scalar expression); >Description >2 The assert macro puts diagnostic tests into programs; it expands to a void >expression. When it is executed, if expression (which shall have a scalar type) >is false (that is, compares equal to 0), the assert macro writes information >about the particular call that failed (including the text of the argument, the >name of the source file, the source line number, and the name of the enclosing >function — the latter are respectively the values of the preprocessing macros >__FILE__ and __LINE__ and of the identifier __func__) on the standard error >stream in an implementation-defined format.159) It then calls the abort >function. >Returns >3 The assert macro returns no value. >Forward references: the abort function (7.20.4.1). >159) The message written might be of the form: >Assertion failed: expression, function abc, file xyz, line nnn. >§7.2.1.1 Library 169 > > >>What tools exists for doing buffer overflow checks? > >http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ >http://www.cigital.com/its4/download.php >http://www-106.ibm.com/developerworks/rational/library/811.html >http://www.automatedqa.com/downloads/aqtime/aqtime3.asp >http://www.compuware.com/products/devpartner/bounds.htm >http://www.parasoft.com/jsp/products/home.jsp?product=Insure >http://www.microquill.com/heapagent/ha_demo.htm >http://perens.com/FreeSoftware/ElectricFence/ > >>I'm using VS.Net 2003 for my dev environment. I'd like >>to make sure that if I have a char x[10] that i'm >>never stuffing more than 10 bytes into it using strcat etc. >> >>I realized both of these questions are because I'm pretty >>new to C/C++ programming. So please excuse my ignorance on >>these subjects. >> >>Thanks, >>Eric Dann, Thanks for the response. What i'm doing now is pretty much the same thing as the ASSERT macro. That is, when i get a failed assertion, I get information about the file and line number the assert failed on. For instance I know that in a game last night a situation occured in the piece_remove function where the piece it was trying to remove didn't exist. I get the following information in the log. FATAL 27601 file ".\board.cpp", line 405, assertion "board->pieceat[position]==piece" failed OUTPUT 27601 file ".\board.cpp", line 405, assertion "board->pieceat[position]==piece" failed What would be even better would be to know if the piece remove function was being called from either move_apply() or move_undo(), and just as useful would be to know what function was calling those. I could come up with a few schemes that would allow me to dump certain information before letting the ASSERT terminate the program. but getting the call stack would be great if possible. You mentioned that there aren't any "portable" ways to do this. Does that mean that there are some platform/compiler specific ways it can be accomplished? I would be ok with trying those as of course this is only being compiled into a special low-performance, bug-finding version of the executable. and wouldn't lose portability for other builds. Eric PS. thanks also for the list of bounds-checkers and your earlier post last night!
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.