EGBB implementation

[Kempelen]

Code: Select all

		 //HERE LOADTYPE IS (SHOULD BE) LOAD_4MEN
		 loadegbb(mainpath,cachesize,loadtype);

That is how I have it. Maybe it is a problem of mingw which is the compiler I use.

I have copied the engine and bb in an xp I have and it crashs as the same point (in this position: 8/8/8/2p5/8/8/1kP1K3/8 b - -)

No idea what is the problem....

[Daniel Shawul]

Here is what i have in scorpio. BTW does scorpio crash too in your system ?

Code: Select all

enum egbb_colors {
	_WHITE,_BLACK
};
enum egbb_occupancy {
	_EMPTY,_WKING,_WQUEEN,_WROOK,_WBISHOP,_WKNIGHT,_WPAWN,
    _BKING,_BQUEEN,_BROOK,_BBISHOP,_BKNIGHT,_BPAWN
};
enum egbb_load_types {
	LOAD_NONE,LOAD_4MEN,SMART_LOAD,LOAD_5MEN
};

#define _NOTFOUND 99999

typedef int (CDECL *PPROBE_EGBB) (int player, int w_king, int b_king,
							int piece1, int square1,
							int piece2, int square2,
							int piece3, int square3);

typedef void (CDECL *PLOAD_EGBB) (char* path,int cache_size,int load_options);
static PPROBE_EGBB probe_egbb;

int SEARCHER::egbb_is_loaded;
int SEARCHER::egbb_load_type = LOAD_4MEN;

/*
Load the dll and get the address of the load and probe functions.
*/

#ifdef _MSC_VER
#	ifdef ARC_64BIT
#		define EGBB_NAME "egbbdll64.dll"
#	else
#		define EGBB_NAME "egbbdll.dll"
#	endif
#else
#	ifdef ARC_64BIT
#		define EGBB_NAME "egbbso64.so"
#	else
#		define EGBB_NAME "egbbso.so"
#	endif
#endif

#ifndef _MSC_VER
#    define HMODULE void*
#    define LoadLibrary(x) dlopen(x,RTLD_LAZY)
#    define GetProcAddress dlsym
#endif

LoadEgbbLibrary modifies the egbbpath slightly.

Code: Select all

int LoadEgbbLibrary(char* main_path,int egbb_cache_size) {

#ifdef EGBB
	HMODULE hmod;
	PLOAD_EGBB load_egbb;
	char path[256];
	char terminator;
	size_t plen = strlen(main_path);
	strcpy(path,main_path);
	if (plen) {
		terminator = main_path[strlen(main_path)-1];
		if (terminator != '/' && terminator != '\\') {
			if (strchr(path, '\\') != NULL)
				strcat(path, "\\");
			else
				strcat(path, "/");
		}
	}
	strcat(path,EGBB_NAME);
	if((hmod = LoadLibrary(path)) != 0) {
		load_egbb = (PLOAD_EGBB) GetProcAddress(hmod,"load_egbb_5men");
     	probe_egbb = (PPROBE_EGBB) GetProcAddress(hmod,"probe_egbb_5men");
        load_egbb(main_path,egbb_cache_size,SEARCHER::egbb_load_type);
		return true;
	} else {
		print("EgbbProbe not Loaded!\n");
	}
#endif
	return false;
}

[Daniel Shawul]

fixed input with dynamic _colorToMove_:

col = white/black;(brd->ctm)
p[0]=6;
p[1]=4;
p[2]=6;
s[0]=17;
s[1]=27;
s[2]=45;
pwk =9;
pbk =30; // !unpredictable error occurs!

Is this the postion ?
[D] 8/8/5P2/8/3B2k1/1P6/1K6/8 w KQkq - 0 1

[Desperado]

Code: Select all

		 //HERE LOADTYPE IS (SHOULD BE) LOAD_4MEN
		 loadegbb(mainpath,cachesize,loadtype);

That is how I have it. Maybe it is a problem of mingw which is the compiler I use.

I have copied the engine and bb in an xp I have and it crashs as the same point (in this position: 8/8/8/2p5/8/8/1kP1K3/8 b - -)

No idea what is the problem....

@Fermin
-----------

first check the following checklist:

-correct path
-correct implementation of path (slash issues)
-latest known dlls and data
-Loadlibrary issues
... and some other things

further load the correct dll

Code: Select all

	#ifdef _WIN64
		#define EGBB_NAME "egbbdll64.dll"
	#else
		//HERE ALSO "egbbdll.dll" WAS DOING THE JOB
		#define EGBB_NAME "egbbdll32.dll"
	#endif

@Daniel:
-------------

- egbb loaded correctly (4+5 men)
- egbb probes correctly (4men always ok, 5men has exceptions)

These exceptions look like:

probing position X : ok
probing position Y : ok
probing .... : ok
probing position X : ok
probing position A : ok
probing position X : CRASH ????

Why can position X suddenly crash ?
What can be the matter with the os here ?

while trying to fix this i did the following:

- ignored the return value of my testBitbase function,
which calls the probeEgbb.

Bughunting part1:

fixed input to the probeEgbb function (positionX)
(all params to probeEgbb were const so to say)
everthing worked, no access violations.

Bughunting part2:
- fixed input to the probeEgbb
(all params const, only switched side to move dynamically)
Now access violations were occuring!

this position can be found above in the thread.
(and it was not the only position causing an exception of this kind).

Code: Select all

Bughunting part 1a: ok(no errors)

col = white; 
p[0]=6; 
p[1]=4; 
p[2]=6; 
s[0]=17; 
s[1]=27; 
s[2]=45; 
pwk =9; 
pbk =30; //all was running fine 

Bughunting part 1b: ok(no errors)

col = black; 
p[0]=6; 
p[1]=4; 
p[2]=6; 
s[0]=17; 
s[1]=27; 
s[2]=45; 
pwk =9; 
pbk =30; //all was running fine 

Bughunting part 2: (with access violation)

col = brd->ctm; //color to Move, assert(ctm==black || ctm==white)
p[0]=6; 
p[1]=4; 
p[2]=6; 
s[0]=17; 
s[1]=27; 
s[2]=45; 
pwk =9; 
pbk =30; // works n calls, n+1 call is _Access Violation_

Well, at the moment, i cannot test, because i setup my comp last
weekend and dont have the bitbases(and my testproject) at hand at the moment.
(Tommorrow i will reinstall the bitbases and my testproject
to do further tests if someone likes)
My current project doesnt include egbb-handling yet.

Michael

[Desperado]

PS:

fixed input with dynamic _colorToMove_:

col = white/black;(brd->ctm)
p[0]=6;
p[1]=4;
p[2]=6;
s[0]=17;
s[1]=27;
s[2]=45;
pwk =9;
pbk =30; // !unpredictable error occurs!

Is this the postion ?
[D] 8/8/5P2/8/3B2k1/1P6/1K6/8 w KQkq - 0 1

Yes...(was writing my post at the moment...)

[Daniel Shawul]

I reproduced the bug on my laptop Ok it is now time for me to bug hunt. I suspect a corrupted bitbase or a bug in the implementation of the cache. Why else would it show up only the second time we try a postion ?. I guess that the reason it didn't show up frequently was because i immediately store probed positions in the normal transposition tables avoiding the need to probe again... Stay tuned.

[Desperado]

I reproduced the bug on my laptop Ok it is now time for me to bug hunt. I suspect a corrupted bitbase or a bug in the implementation of the cache. Why else would it show up only the second time we try a postion ?. I guess that the reason it didn't show up frequently was because i immediately store probed positions in the normal transposition tables avoiding the need to probe again... Stay tuned.

sorry for this.

i would check your caching issues first. If it would be a corrupted
bitbase there should be an immediate access violation ?!
(and not on n+1 access).

(thought of the transposition table issue too,but was running
my tests on a pure alphaBeta frame )

Good luck on hunting!

[Daniel Shawul]

Oops... I wrongly set the castling flags to "KQkq". That was why it was crashing. Now the problem doesn't exist with this postion
[D] 8/8/5P2/8/3B2k1/1P6/1K6/8 w - - 0 1

[Desperado]

ok, but i dont see how the castle status is influencing the params
given to the probe function.

Additionally, i cannot explain to me why the hard-coded input
for the probe function can produce an error outside the dll !?

Did you make sure the position(this input) is probed multiple-times within your search, did you hard-coded the input?

Micha

[Daniel Shawul]

The move generator I have inside produce castling moves. In fact scorpio sent Ke1-g1 as best move?? The move generator produces castling moves even if there are no rooks The old bit bases also crash at this illegal position so this is definitely not a new problem.
Using scorpio you can "setboard the position" and then "score" multiple times to probe it. No problems there.

I have uploaded the source code of egbb probe which compiles with no problems with VS 2008 after i removed tons of warnings associated with deprecated functions. So please try http://www.geocities.com/dshawul/egbbdll_new.zip, and see if there is any change.