Possible stockfish 1.91 bug

[jwes]

Twice now I have let stockfish analyze a position for several days and it has unexpectedly exited. I am using the 1.91 ja 64 bit compile on a core 2 duo with windows 7. This is frustrating for me and might be even more frustrating to track down.

[wgarvin]

Twice now I have let stockfish analyze a position for several days and it has unexpectedly exited. I am using the 1.91 ja 64 bit compile on a core 2 duo with windows 7. This is frustrating for me and might be even more frustrating to track down.

Maybe you could start the engine, and then attach a debugger to it. Then if it performs an invalid memory access or something, it will stop there in the debugger. Obviously this will work better if you have it compiled with some debug information (e.g. an optimized build with symbols line numbers?). With this, you might be able to see what function it's crashing in. [Edit: another possibility is just to link it with a map file, and then compare the address from the crash dialog with the symbols in the map file to find out which function it is. But that is tedious.]

Maybe its overflowing some fixed-size buffer, related to the large depth?

[michiguel]

Twice now I have let stockfish analyze a position for several days and it has unexpectedly exited. I am using the 1.91 ja 64 bit compile on a core 2 duo with windows 7. This is frustrating for me and might be even more frustrating to track down.

Maybe you could start the engine, and then attach a debugger to it. Then if it performs an invalid memory access or something, it will stop there in the debugger. Obviously this will work better if you have it compiled with some debug information (e.g. an optimized build with symbols line numbers?). With this, you might be able to see what function it's crashing in. [Edit: another possibility is just to link it with a map file, and then compare the address from the crash dialog with the symbols in the map file to find out which function it is. But that is tedious.]

Maybe its overflowing some fixed-size buffer, related to the large depth?

With assert()'s that check an extra byte strategically placed at the end of the fixed-size buffers (related to depth), reduce the size of those arrays to a ridiculously small number (maxdepth = 8, for instance). Then, run the engine in debug mode. Even in this stress test, the engine should not crash or fire an assert(). I strongly suggest to run these stress tests once in a while as part of a routine.

Miguel

[jwes]

Twice now I have let stockfish analyze a position for several days and it has unexpectedly exited. I am using the 1.91 ja 64 bit compile on a core 2 duo with windows 7. This is frustrating for me and might be even more frustrating to track down.

Maybe you could start the engine, and then attach a debugger to it. Then if it performs an invalid memory access or something, it will stop there in the debugger. Obviously this will work better if you have it compiled with some debug information (e.g. an optimized build with symbols line numbers?). With this, you might be able to see what function it's crashing in. [Edit: another possibility is just to link it with a map file, and then compare the address from the crash dialog with the symbols in the map file to find out which function it is. But that is tedious.]

Maybe its overflowing some fixed-size buffer, related to the large depth?

With assert()'s that check an extra byte strategically placed at the end of the fixed-size buffers (related to depth), reduce the size of those arrays to a ridiculously small number (maxdepth = 8, for instance). Then, run the engine in debug mode. Even in this stress test, the engine should not crash or fire an assert(). I strongly suggest to run these stress tests once in a while as part of a routine.

Miguel

I am hoping that the authors of stockfish will debug this. I did notice that the error exit logs to stderr, which unfortunately is not redirected.