RuntimeError: memory access out of bounds

[mcaap]

I am facing the same issue as this user when using stockfish-16.1-single.js and stockfish-16.1-lite-single.js versions.
I only use it for analysis on Mac with node/vuejs.
Analysis starts fine and if I wait for the "best move" before analyzing the next position in that game, its all ok.
But if I quickly play through the moves while the engine is running, then after 4 or 5 moves I get this:

stockfish-16.1-single.js:8 Uncaught RuntimeError: memory access out of bounds
    at stockfish-16.1-single.wasm:0x54c90
    at r.<computed> (stockfish-16.1-single.js:8:9332)
    at stockfish-16.1-single.js:8:9715
    at se (stockfish-16.1-single.js:8:4624)
    at stockfish-16.1-single.js:8:10785

Engine.vue UCI <- {} Aborted(RuntimeError: unreachable)
stockfish-16.1-single.js:8 Uncaught RuntimeError: Aborted(RuntimeError: unreachable). Build with -s ASSERTIONS=1 for more info.
    at C (stockfish-16.1-single.js:8:3920)
    at x (stockfish-16.1-single.js:8:9154)
    at stockfish-16.1-single.js:8:9576
    at se (stockfish-16.1-single.js:8:4624)
    at stockfish-16.1-single.js:8:10785

=============
Steps to reproduce this error on Mac OS 14.5 (Apple M1 pro) via command line:

node src/stockfish-16.1-single.js
uci

keep pasting this command and hit enter multiple times:

go depth 19
go depth 19
go depth 19
go depth 19

Error:

RuntimeError: memory access out of bounds
    at wasm://wasm/108df99a:wasm-function[425]:0x54c90
    at r.<computed> (/Users/mcaap/Downloads/stockfish.js/src/stockfish-16.1-single.js:8:9332)
    at /Users/mcaap/Downloads/stockfish.js/src/stockfish-16.1-single.js:8:9715
    at se (/Users/mcaap/Downloads/stockfish.js/src/stockfish-16.1-single.js:8:4624)
    at Timeout._onTimeout (/Users/mcaap/Downloads/stockfish.js/src/stockfish-16.1-single.js:8:10785)
    at listOnTimeout (node:internal/timers:581:17)
    at process.processTimers (node:internal/timers:519:7)

Same happens with : node src/stockfish-16.1-lite-single.js

However, the multi thread versions work fine and dont have this crash: node src/stockfish.js

[erjoalgo]

I seem to be able to reproduce the crash with the multithreaded version:

Stockfish 16.1 WASM Multithreaded by the Stockfish developers (see AUTHORS file)
worker sent an error! http://localhost:9091/src/stockfish.js:38: Uncaught RuntimeError: memory access out of bounds

Using ./src/stockfish-16.1.js

[0xVegeta]

I am facing the sme issue while using stockfish-17-lite-single.js and stockfish-17-lite-single.wasm

stockfish.wasm:0x52e60 Uncaught RuntimeError: memory access out of bounds
    at stockfish.wasm:0x52e60
    at r.<computed> (stockfish.js:654:32)
    at f.ccall (stockfish.js:1054:20)
    at t.sendCommand (stockfish.js:1297:28)
    at onmessage (stockfish.js:1322:38)

[DoctorDerek]

I encountered this exact "memory access out of bounds" error with stockfish-17-single.js in my web app while using XState for logic. The issue seemed to stem from sending UCI commands like stop, position fen..., and go in very quick succession, particularly when interrupting an ongoing analysis or search (go infinite or go depth X) to start a new one almost immediately.

The fix in my case was to simplify the command sequence sent to the Stockfish worker: I stopped automatically sending go infinite during the opponent's turn and removed explicit stop commands right before sending a new position fen... / go depth....

It seems relying on the engine's implicit behavior to stop the previous search when receiving a new go command was more stable than trying to manage stop explicitly in rapid sequences. I now only send stop when truly necessary (like game over or error state). This resolved the crash for me.

Hope this helps!

[DoctorDerek]

I'm still having this issue sometimes when sending "stop" followed immediately by a go e.g. "go movetime 1000"; I guess I need to put in a delay to prevent some race condition from crashing the app.

Then again, my particular issue might not be that.

I occasionally see something about Stockfish recommending an illegal move, which then doesn't get played. That could cause the crash.

It's hard to tell, but I'll be following the discussion here. 🥰

[bklaric]

I was running into this with stockfish-17-lite-single.js running in the browser . What seems to be working so far is sending position and go only after I've received bestmove from the previous run. If I tell it to go while it's still calculating, it gets messed up. If I tell it to stop, I have to make sure to wait for bestmove as well.

[nmrugg]

I was running into this with stockfish-17-lite-single.js running in the browser . What seems to be working so far is sending position and go only after I've received bestmove from the previous run. If I tell it to go while it's still calculating, it gets messed up. If I tell it to stop, I have to make sure to wait for bestmove as well.

Yes, this is necessary. I'll see if I can work around this problem internally.

[mattslight]

This is correct. I was not able to reproduce the issue with stockfish-17-lite.js – I assume because it can use multiple threads and start a new search before the another one truly finishes. Without deeper understanding of the code I couldn't say for sure.

Luckily browser coverage for SharedBufferArray is high – https://caniuse.com/sharedarraybuffer