Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

StockfishChess

A topic by Byte GameMaker Magazin created Dec 24, 2023 Views: 382 Replies: 7
Viewing posts 1 to 5

Unfortunately there is a problem with StockfishChess. From a certain search depth (this varies depending on the UCI engine, settings, PC and position) it unfortunately crashes. With fairy-stockfish, for example, I get a depth of 13. At 14 it becomes unstable, from 15 it crashes in almost every position. As a result, this actually great extension for depth analyses (>24 plys, better 30) is unfortunately not usable. :-(

It would be great if you could fix the error.

Developer (6 edits)

Does the crash only happen with fairy-stockfish? Or does it happen with the default stockfish app which comes with the extension? It is my understanding the demo doesn't come with fairy-stockfish in specific, so it wasn't intended for that. Another user on discord already reported this to me with fairy-stockfish, and they ended up using a different chess engine entirely as their workaround to solve this issue. Unfortunately, this demo was made for a client and they seemed happy with it, but I can't comment much on the stability of it because while I did write the demo I don't actually know much about stockfish or command line chess engines as a whole, so I'm not the person to be much a help here. The demo was meant to show what can be done from the command line with various apps, and stockfish was just the command line app chosen for the demo, and mileage will vary across command line apps.

Also, I can't remember who pinged me on discord about stockfish, and I have way too many messages to dig through of support tickets to really go about finding who they were much less what chess engine they settled on; maybe if they read this topic they could comment and help you out.

I apologize for the inconvenience. I was never able to figure out the root cause of the crash and I've already spent as much time on trying to figure that one out as I would like.

One thing to make note of with any command line app you try to read standard output from is the buffer might overflow, which causes crashes. This happens when the string returned and sent to standard output is too large for the app to hold it in memory, and so it will close abruptly (crash) in such case. The extension used to store standard output in a string, called xProcess, does not truncate the string at all if it gets too big, though I doubt buffer overflow is the reason you get the crash you are facing. This note is more of a "so you know" for general rule of thumb in case you, (or anyone else for that matter), uses my xProcess extension for anything besides stockfish.

fairy-stockfish was just an example. It was derived from Stockfish. I have tested it with several UCI engines, including all Stockfish versions from 12 to 16, Polyfish, Komodo Dragon and others. When exactly the crash occurs varies. This also depends on how the chess engine was compiled. With fairy-stockfish it runs reasonably stable at a depth of 12 half-moves. It "only" crashes every 100th game. But 12 half-moves is far too little to do anything sensible with it.

A buffer overflow was my first assumption. So I installed it in between so that after each move the engine is restarted, FEN is sent and global.output="" is set. Unfortunately, that didn't help. There were also problems because I change the engine in the middle of the game, but I solved that. Now it is called, I send FEN for every move, but it runs through.

My current guess is this: Greater depth means that the engine pauses at some point, so it doesn't send anything. I suspect that because the EXE is not responding, synchronization is lost.

If you give me another contact, Discord or mail, I can also send you screenshots or the current version. It's a pretty big project by now and it would be a shame if it were to fail.

Developer

My discord is "samuelvenable". Try downloading the project again and see if the new version of the extension fixes it. I added a new function which allows you to limit the buffer length to a specific number of characters, (including the null byte at the end). For example:

SetBufferLimitForStandardOutput(2048);

...will limit the buffer to 2,048 of the most recent characters.

It's great that you're still working on it. I have tested your version. It crashes for me at a depth of 40.

ExecutedProcessWriteToStandardInput(global.pid, "go depth 40\n");

I'll get in touch with you via Discord when I get a chance.

Developer

For readers of this topic who aren't aware, I am talking with Byte GameMaker Magazin on Discord and behind the scenes I have been able to reproduce the bug he mentioned, though it is confirmed to be a Windows-only bug. Meaning it will not crash on macOS or Linux for anyone, making the extension/demo still valid/useful way more than it would be if it crashed on all platforms, (which it doesn't). Most people use Windows in the marketshare though, so this bug is considered crucial and I am making it a priority to fix it. I might get help from the boost process lead developer when he is less busy, if I am unable to figure this one out by myself.

Developer (9 edits)

For readers of this topic, I was able to narrow down the issue further, and it turns out that this is not a bug with the extension/demo itself, but rather a bug with GameMaker. I just tried the extension in a different game engine, a GameMaker clone called STIGMA, I maintain, (my fork of ENIGMA), and it doesn't crash on any platform, not even on Windows. Since both STIGMA and GameMaker rely on identical code for the xProcess extension, this is how we know it is a bug with GameMaker and not my extension. You can download the EXE made with STIGMA yourself if you would like to see for yourself what I am talking about:




https://github.com/time-killer-games/ENIGMA-StockfishChess-Demo/releases/downloa... You will notice if you leave the EXE running for a long time (it has the depth set to 1,000) it won't ever crash. I am going to report this bug to YoYoGames, but it is so specific to my extension and doesn't really effect any other projects, I doubt they will fix it, so no one should hold their breath or be the least bit hopeful about this. Previous download link includes a Windows EXE, macOS APP. Linux ELF, and not to mention there is also the GM81 project file which may be edited and compiled with STIGMA. STIGMA can be downloaded here: https://samuel-venable.itch.io/stigma-development-environment

Developer (2 edits)

I think I might have fixed the crash you were experiencing with xProcess and chess engines. Here's a test project I sampled which used to crash but no longer does: shogi_demo.yyz. At least for me, anyway. Import the version of the xProcess extension from the YYZ into your chess game project and see if that fixes it. (While deleting the old version of xProcess in your project). Here's to hoping you haven't deleted your game project file. The crash happened because the DLL was compiled with Visual Studio. Compiling with MinGW/GCC instead fixed it. Really stupid solution, but at least it works now. Since STIGMA uses MinGW/GCC as its compiler on Windows, that explains why it didn't crash.