Stack overflow at high depths when all=yes

[ianfab]

Reproduce

Compile with all=yes.

Input:

setoption name UCI_Variant value gustav3
position fen arnbqkbnra/*ppp1pppp*/*3p4*/*8*/*8*/*N1P5*/*PP1PPPPP*/AR1BQKBNRA b KQkq - 0 2 moves f7f5 f2f3 d8e7 e2e4 i7i5 i2i4 j8g5 c2c3 c8d6 a1c2 h8g6 c2d2 f5f4 h1f2 e6e5 j1g4 b7b6 g4g5 e7g5 f2g4 a8b7 d2f2 d6f7 d3d4 d7d6 b3d2 b7d8 d1b3 c7c5 e1e2 g5h4 g2g3 h4e7 f2h3 f7g5 h3h5 g8b3 d2b3 d8f7 b3d2 b6b5 b1d1 g6h8 h5f7 h8f7 f1g2 c5d4 c3d4 b8c8 g1f2 f7h6 d4e5 h6g4 f3g4 d6e5 d2f3 f8h8 f3g5 e7g5 g3f4 g5f4 d1d6 h7h6 d6d5 c8c4 b2b3 c4c3 d5d3 c3d3 e2d3 e8c8 g2h3 g8d8 d3b5 c8c2 f2g3 d8d3 i1g1 d3b3 b5f1 c2e4 f1d1 b3d3 d1b1 h8i7 g1d1 f4d2 b1b2 e4e2 b2b7 i7h7 d1g1 e5e4 g1g2 e2f3 b7b5 d2g5 b5f5 f3f5 g4f5 e4e3 g2b2 d3d4 b2b6 d4e4 b6e6 e4e6 f5e6 h7g6 h3g4 g6f6 g4f3 f6e6 g3c7 g7g6 h2h3 h6h5 c7g3 h5i4 h3i4 g5h6 f3e4 e6f6 g3e5 f6f7 e5g3 f7f6 g3e5 f6f7 e5g3 f7e6 g3e1 e6d6 e1b4 d6e6 b4e1 e6f6 e1g3 e3e2 e4f3 f6g5 g3f2 h6g7 f2g3 g7h6 g3f2 g5f5 f2g3 h6f8 g3f2 f8g7 f2e1 g6g5 e1g3 g7f8 g3e1 g5g4 f3e2 f5f4 e2f2 f8e7 e1d2 f4f5 d2h6 e7h4 f2g2 f5g6 h6e3 g4g3 e3d2 g6f5 g2f3 g3g2 f3g2 f5g4 d2h6 h4e1 h6i5 e1i5 g2f1 i5h4 i4i5 h4i5 f1g2 i5e1 g2f1 e1d2 f1g2 d2c1 g2f1 c1b2 f1e1 b2a1 e1d1 a1b2 d1e2 b2a1 e2d1 a1b2 d1e2 g4g5 e2f1 b2a1 f1e1 a1b2 e1e2 b2a1 e2d1 a1b2 d1e2 b2a1 e2d1 g5h5 d1c1 a1b2 c1b1 b2a1 b1a1 h5g4 a1b1 g4f3 b1a1 f3e2 a1b1 e2d1 b1a1
go

Output:

info depth 70 seldepth 2 multipv 1 score cp 0 nodes 89856 nps 477957 tbhits 0 time 188 pv d1c1
Segmentation fault (core dumped)

Debug

Input:

$ cat test.fen 
10/*8*/*8*/*8*/*8*/*8*/*8*/K2k6 b - - 8 115

valgrind --tool=drd --show-stack-usage=yes ./stockfish bench gustav3 16 1 100 test.fen

Output:

thread 5 finished and used 8386175 bytes out of 8384512 on its stack. Margin: -1663 bytes.

[benwh1]

I see there was a commit to reduce the max depth to 60 on all=yes, however I just got a segfault at depth 45 on atomic using the latest commit:

Build: make build ARCH=x86-64-modern -j4 all=yes debug=yes Run: valgrind --tool=drd --show-stack-usage=yes ./stockfish

setoption name UCI_Variant value atomic
position fen 7k/8/8/p6p/8/6KP/6P1/8 w - - 0 33
go
...
info depth 45 seldepth 50 multipv 1 score cp -720 upperbound nodes 3794258 nps 9586 hashfull 476 tbhits 0 time 395795 pv g3f4 a5a4
info depth 45 currmove g3f4 currmovenumber 1
==128034== 
==128034== Process terminating with default action of signal 11 (SIGSEGV)
==128034==  Bad permissions for mapped region at address 0x5AFEBB8
==128034==    at 0x1589FD: Stockfish::Position::legal(Stockfish::Move) const (position.cpp:981)
==128034== thread 1 finished and used 273903 bytes out of 8388608 on its stack. Margin: 8114705 bytes.
==128034== thread 2 finished and used 8385735 bytes out of 8384512 on its stack. Margin: -1223 bytes.
==128034== 
==128034== For lists of detected and suppressed errors, rerun with: -s
==128034== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23754 from 151)
Segmentation fault (core dumped)

[RainRat]

Maybe I'm looking at it too simply, but if it's not enough, make it bigger.

thread_win32_osx.h:

static const size_t TH_STACK_SIZE = 8 * 1024 * 1024;

types.h

#pragma comment(linker, "/STACK:8000000") // Use 8 MB stack size for MSVC

[ianfab]

Sure, but at some point you will likely reach the limit of the OS, so I don't think this really is a solution. Consuming so much stack anyway is kind of a bad practice, so we should perhaps dynamically allocate the move list, at least when allvars is enabled. How much this would affect performance remains to be seen.

[ianfab]

Closed in #780