SzG wrote:Well, it may have the same reason that my problem here.
I let Crafty (JA 64-bit compile) play under Arena and restart the engine each time a new game is started. When Crafty starts, task manager reports a use of 247 MB (hash is set to 192, phash to 32, 5-men EGTB's with 32 MB cache used). By the end of the game (40/4 time control on a 3GHz Q6600, 2 threads) the reported memory is already 419 MB.
Now my guess is that because some internal error Crafty wants to allocate more and more memory and when the physical memory limit is reached, it crashes.
I have met this problem before, don't know of a solution.
I've compiled some builds which use Crafty's Unix/Linux threading code
and the 3rd party Windows pthread libraries.
These builds seems to work ok.
Download contains both Intel compiler 10 win32 & x64 Crafty 22.4 test p.g.o builds.
SzG wrote:Well, it may have the same reason that my problem here.
I let Crafty (JA 64-bit compile) play under Arena and restart the engine each time a new game is started. When Crafty starts, task manager reports a use of 247 MB (hash is set to 192, phash to 32, 5-men EGTB's with 32 MB cache used). By the end of the game (40/4 time control on a 3GHz Q6600, 2 threads) the reported memory is already 419 MB.
Now my guess is that because some internal error Crafty wants to allocate more and more memory and when the physical memory limit is reached, it crashes.
I have met this problem before, don't know of a solution.
I just fixed this in 22.5, it was a problem in how threads were created. For windows, it hit the WinMalloc() every time the threads were started. Normally this is just once, unless you use the SMPNICE=1 feature. This should work cleanly now...
However, whether it caused the problem mentioned with the abort is unknown. That output is debug output that should _never_ be hit...
bob wrote:
However, whether it caused the problem mentioned with the abort is unknown. That output is debug output that should _never_ be hit...
Well, I'll compile 22.5 and let you know if it happens again. Do you think that the position that generated the crash is relevant, or could any deep search
have conceivably led to the same outcome?
bob wrote:
However, whether it caused the problem mentioned with the abort is unknown. That output is debug output that should _never_ be hit...
Well, I'll compile 22.5 and let you know if it happens again. Do you think that the position that generated the crash is relevant, or could any deep search
have conceivably led to the same outcome?
This is a _very_ difficult debugging task. I have found a position here and there that would cause Crafty to crash, and if I run it 30 times, it might only crash once. That makes these tough to find. I am not seeing any crashes with the current version, however, and I have been running it on ICC using an 8-core box for a week or so, as that will usually expose any "crashing bugs" pretty clearly where Crafty will lose on time and the log file will show that status...
If I were debugging what you are looking at, I would run it several times, but would realize that it could be a problem left around by a previous search, so that just setting up the position might not reproduce the bug, ever...
I assume you are using a parallel search, which is by far the most complex part of Crafty from a debugging perspective. the parallel search code is very "lean and mean" and has been studied many times by me looking for potential issues or performance improvements. Most of these ugly bugs creep in with eval changes where I use the wrong subscript type and index into a small array with a big subscript. Which might or might not hurt a thing depending on what is at that subscripted value's address...
SzG wrote:Well, it may have the same reason that my problem here.
I let Crafty (JA 64-bit compile) play under Arena and restart the engine each time a new game is started. When Crafty starts, task manager reports a use of 247 MB (hash is set to 192, phash to 32, 5-men EGTB's with 32 MB cache used). By the end of the game (40/4 time control on a 3GHz Q6600, 2 threads) the reported memory is already 419 MB.
Now my guess is that because some internal error Crafty wants to allocate more and more memory and when the physical memory limit is reached, it crashes.
I have met this problem before, don't know of a solution.
I've compiled some builds which use Crafty's Unix/Linux threading code
and the 3rd party Windows pthread libraries.
These builds seems to work ok.
Download contains both Intel compiler 10 win32 & x64 Crafty 22.4 test p.g.o builds.
That might or might not work. See my comments about the "detached thread mode" issue I found in the linux pthreads library defaults. 22.5 ought to fix both of these problems...
