Author: Dann Corbit
Date: 13:22:29 06/16/05
Go up one level in this thread
On June 16, 2005 at 15:28:55, Eric Oldre wrote: >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? In C++ under .NET compiles, you can throw an exception and then process the exception message which will contain the call stack. Or something like this (also totally non-portable): http://www.codeproject.com/debug/extendedtrace.asp >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.