• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Games
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.3
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Rockbox
Opened by Skyly - 2009-06-21
Last edited by Bilgus - 2019-08-04

FS#10363 - Chessbox playing errors and crashing

I’m using Version 3.3 now, and found this problem in 3.2 as well.

Basically, sometimes when the DAP is processing its next move, it wigs out and switches sides instead. In a game where I was playing white, now all the pieces have flipped sides and I am black.

Except, now I’m black AND white.
Plus I can just keep moving white, on the other side of the screen, and never move black.

This didn’t used to happen but is strangely becoming more common, to the point where sometimes it breaks after my very first move.

*Tries it right now*
.. And yes, after my 2nd move it has fallen over again.

Now white is at the top of the screen, and I can just keep moving white’s pieces without black ever having a turn. Until…

at 32F742C

Fortunately, this is a nice crash and when I press play, the unit reboots.

If it’s of any help, this didn’t happen until the day black put itself in Check. That is to say, he moved a piece blocking Check out of the way, so on my turn I was able to actually kill (not just checkmate) the king.
Once that was done, the game actually kept going. Black simply had one less piece to defend heh.

Anyone else run into this?

Closed by  Bilgus
2019-08-04 18:59
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

PGN Saving fixed in latest dev as well

yes, this happens to me all the time (ipod gen5 30GB). especially on saved games. quite annoying as i have to hard-boot the player.

This problem is boring me endlessliy. Anyone an Idea how to manage it? I’m running rockbox ob my iaudio x5l everything else is doing perfect job.

Same problem here with Sansa Clip and Sansa Fuze

Same since years on my pimped X5XXL 120GB.
I did quit playing chess on it. It is a pity.

Nevertheless Rockbox is one of the greatest thing that could happen to me.
I am using it since at least a decade on my iAudio M3 and iAudio X5L.
And this little piece of free software gave me hundreds of hours of pleasure with my music collection I would never had with original firmware nor CDs nor with mp3s on a computer.
Folder management and live copy and paste made my best playlist folders for chill out and dancing.


dbx commented on 2016-05-08 09:33

Sadly, looks like I’ll be humbly throwing my hat into the polite bug solution request ring.

Seven years without nary a slight interest of any kind soul towards resolution.

This development is honestly one of my most beloved features of Rockbox.

Everything happens in exactly the same fashion as Dan (Skyly) has described.

Most unfortunately, the board flips when I have the AI “on the ropes” and never the reverse ::smile::.

[SanDisk Sansa Clip Zip]

To flip boards, press select and right arrow (repeat if necesary).

Typing “del R:\.rockbox\rocks\games\chessbox.log” where R: is whatever drive your player is on should allow normal play again. No, this isn’t a bug, but a feature. (I learned there are no bugs in rockbox from the experts here. Just undocumented features.) Also, when they say “every move you make … I’ll be watching you”, they meant it literally.


Can someone supply me with a .pgn and .save exhibiting this behavior I’ve been playing chess for hours now trying to reproduce but so far no dice

What is the current size of your chessbox.log file and what device are you using?


no .log on any of the devices I’ve tried on, Clip+ (unbearably small) fuze+ ( played 30+ rounds varying levels restore saves and new games) If you don’t have either of those I’ll do it in the sim

That’s strange you don’t get the log file and the zip builds do. Without that log file, you shouldn’t get the bug. That was the point of my comment. To explain in more detail, when the chess engine is doing deep thinking and the .log file is above perhaps 16k, my working theory is that an out of memory condition causes the engine to flip sides and move prematurely, but only when playing from a saved game. Once I deleted the log file, it worked correctly, except for certain saved games. However, I think that is another bug involving the time allowed for the chess engine to think, is my theory. Unlike the .log “feature”, the saved game out-of-time bug only affects the first chess engine move, and does not involve black/white flips.


ok, Ill try in the ClipZip sim if you want to paste a log+pgn+save that exhibits this behavior I’ll try to reproduce

One think a reader may not know why I said “deep thinking.” The ram required is a strong function of the exact situation the AI is exposed to. If black is in check, for instance, almost no ram will be used, since the number of lines needed to analze is drastically reduced. The engine probably “decides” the best “ply depth” based on the amount of time allowed, move number, and calculated uncertainty about which line of potential moves is best.

Before doing that we need to focus on the discrepancy. You need to confirm that your zip sim is producing a log file after player a single game.


Logs are only invoked if you start the plugin as a viewer of the .pgn file I had to read the source to figure that out so yes I was able to get a .log file


.log on the fuze+ is ~9.1kb with 9 games played

Nice work William. Well, I’m glad I asked, because I don’t think you can invoke the chess game plugin from the .pgn viewer, which is a totally separate program (the chessbox.ovl viewer). Correct me if I’m wrong on that. This implies that my working theory above is at least partially, if not completely, incorrect. If so, my apologies. Before I comment again, I should probably reproduce the bug and do a few tests. When I get a chance, I’ll post again, if nobody else does. My recollection is that the bug definitely only occurred when playing from saved games, so it definitely makes sense to upload a saved game file, as you smartly requested. The total current number of potential variables include the three .log, .pgn, .sav, files, build, and platform, although the .log file variable one is now a very low-probability factor. (Difficulty level of 1 produces the problem, so that is not actually a variable.) I tried playing with a huge .pgn file just now and did not quickly reproduce the bug, so it could be more platform-dependent than I thought. (I tend to consume mp3 players like toilet paper and this is an old bug.)

Wait, something is amiss. William, you implied that the number of games both affects the .log file size and that it doesn’t. “.log on the fuze+ is ~9.1kb with 9 games played” “Logs are only invoked if you start the plugin as a viewer of the .pgn file I had to read the source to figure that out so yes I was able to get a .log file”


trying loading different games doesn’t seem to change the size of the log file, the .pgn changes size with number of games though
The plugin has options to become a viewer

  /* if the plugin was invoked as a viewer, parse the file and show the game list 
   * else, start playing a game
  if (parameter != NULL) {
      cb_start_viewer((char *)parameter);
   } else {

I did finally get a game into the pgn that crashes on data abort though I’ll get back to you

Just to help save time, the worrisome bug is NOT really about any crashing, IMO, and the viewer isn’t used by anyone. It is about the change-sides getting triggered when the engine is thinking deep and the program was loaded normally, which is usually the last game played, without requesting a new game. I will do some tests as soon as a get some spare time but I’ve little now.

Ok, I’ve done a few tests. Place the attached file in X:\.rockbox\rocks\games\, where X: is your mp3 player directory. In the Sansa Clip Zip emulator, or a start chessbox from the plugins, games, chessbox. The saved game should automatically load. Move a white piece. You should note that the engine fails to think the normal amount of time. There is a book, so when you start a game the engine can move quickly, but after you go off book, it takes several seconds at least, even on the level 1. Instead of taking even a single second, it plays very quickly and poorly, as if it has no time to think. It may say checkmate. It should eventually, after 4 moves, flip sides. This implies that it isn’t a .log or .pgn files at all, and my post, and prior theory, was incorrect. My apologies. Based on the data I have, it is almost certainly the case that the two bugs I thought were independent are actually the same bug, and that has to do with the calculation of available time allowed by the engine in saved games, or possibly the writing of the saved game file.

Because the engine is good even at level 1, the engine cannot be beaten in speed play, at least by me, and good games take a long time from start to end. This is why the saved game feature is so useful.

I am not sure why some saved games seemed to work and some did not. My original thoughts assumed the problem was more predictable than it is. Now I can see that the most predictable indication that something is wrong is that the engine moves too quickly. If that happens, the engine will switch sides. Perhaps there is another bug that perhaps instead of resigning when out of time or time left is negative, the engine flips sides. This would make sense if the normal end game routine assumed the game ended by checkmate or stalemate, and out of time was an afterthought or not fully programmed in.

A patch to fix this might fix or even ignore the time setting in the saved game file, or instead save the difficulty level, resetting the time to 5 minutes when you load up a saved game. That might change the difficulty level but it would solve the real problem.

What is the binary field chart of the file? I’d guess the first step is to verify the time left field is stored correctly.


I’ve narrowed down the pgn issue but haven’t quite found the root cause it’s in the parsing routine which AFAICT uses some of the same functions as restore game it’ll be the next day or two before I get a chance to sit down and look at it again but I’ll update here as I figure things out, Ive downloaded the save file and will try it on device/sim ASAP


As far as the save files they are just a blob of the struct values so if it has 10 Ints in the struct then there will be 320 bytes in the file I don’t remember if there is any padding though, but this is the same way most things in RB plugins are written to file as well.

Awesome. I don’t know if this is relevant, but the source is from 1988 and in 1990 a bug was fixed described as “Fixed the check for zero division in Time controls.” ( ). The most recent update is at .


UGH Can Someone Delete Those ^^
Good Save: Bad Save 2 Moves Later:

Excellent progress. What did you do to convert the saved game files to what is on pastebin?


Bad Pgn File


For the save file I went through and snprintf’d all the variables in the same order as the save function ( the names are variations of the actual variables)

Well I don’t propose changing anything really but it does seem crazy to have so much information being saved in a saved game file. For instance, the pgn file also saves all that is needed in perhaps ~1/100 as much space, so the whole saved game file is redundant anyway.

Oh, I see. So you are using a debugger.

Just to clarify, the problem resides within the saved game files, and the save-game subroutine, but we don’t know which variables are being incorrectly saved?

Why are there so many different time variables?

Can you attach the good to confirm that it is really good?


ok try this chessbox.rock with your ClipZip
I’m not sure what this will do to the chess engine’s quality of play as I’m not sure how it uses the old moves but it should fix the crash


ok try this chessbox.rock with your ClipZip
I’m not sure what this will do to the chess engine’s quality of play as I’m not sure how it uses the old moves but it should fix the crash

Bilgus you fixed the bug!!! THANK YOU! If I had any say you’d get some of the alleged or past paypal donation money. I exited and restarted (I did not save and restore, which should use same code) the game about 10 times and it never went into the non-thinking mode except on obviously no-brainer moves like in the middle of an exchange, when there is clearly only one good move. Now this is perhaps the smallest playable and pause-able chess game in the world!

Can you paste the diff?


it is up on gerrit although I suspect pgn saving will be broken so ill probably make it either save on the fly or combine multiple pgn files and merge them later


I just noticed this:
/* TODO: save/restore the PGN history of unfinished games */

So I think i’ll leave well enough alone

I am confused. What does the pgn stuff have to do with the OP’s changing sides/instant-move-AI bug?


I just noticed this:
/* TODO: save/restore the PGN history of unfinished games */

So I think i’ll leave well enough alone


I’m beginning to really hate flyspray with double posting every time I refresh.

The Pgn files use the GameList array to compile the record of moves made..

To fix the bug, GameList[] now rolls over back to 0 instead of just
reading / writing whatever is after the array (overflow) and therefore it
starts overwriting the beginning of the game.
When the beginning of the game become the end of the game pgn_save makes an invalid .pgn
save entry.
This is the cause of the second bug I found while hunting down the
referenced bug, I have added bounds checking to the pgn_restore function which
at least fails gracefully in this case.

Admittedly, The pgn_save function never got called since the first bug
crashed the game and therefore pgn saving was already broken in this case.

I feel it is more important to actually be able to play the game anyway HAHA.

I agree, it is more important to be able to play restored games.

Thanks for the explaination. That might explain my initial false positive, since I deleted all three files at the same time (chessbox.log, chessbox.pgn, and and incorrectly assumed it was the biggest file, the .log file, when it was actually the .pgn saving routine. This may explain why when I did my second round of testing the bug was there again. Anyway, I do like the .pgn auto-creation routine, and hope we can fix it. There are software programs that can indicate the likely ELO scores of the engine and players, just based on the .pgn files, which is sort of a cool thing. However, it is 10x more important to be able to play, save, and restore short games. I think one should also consider the newer code I linked to that the original 1988 author put out. If this .pgn-writing bug you have semi-fixed was in the gnuchess code it is certainly fixed by now.

Not that anyone cares but another method of handling this would be to have separate files for each .pgn game. So game0.pgn, game1.pgn, game2.pgn, etc., with the game9.pgn getting deleted and the others renamed and stuff. But there are a million ways to skin a cat.

“The pgn_save function never got called since the first bug
crashed the game”

Well I’m confused about that. The sympoms I was getting were not crashes but side-flipping preceded by instant and poor moves.


The first bug flipped the board because the game started overwriting the data in other areas of the program but eventually it would crash. The pgn save thing isn’t really a bug per se but a result of just not having enough room to store all that data, what would have to be done is rewrite the pgn saving to do it incrementally and dump each time the array started getting full and really I’m not at all interested in picking apart this code any more than I already have.


Also the pgn stuff was added by the guy who originally did this port AFAICT there is nary a sign of it in the GNUChess source.

You also underestimate the amount of time it would take to re-port this code to rb, if you look at the what you posted vs whats in RB it is very similar in the parts that coincide. Not to mention that code is a text based chess game.

Thanks for explaining. I guess it is time to call it a wrap and close the bug.

Another reason to close it now (before fixing the .pgn game recording) is because the entire game move/recording/spying feature was never disclosed in any manuals. The manuals are a lot of work to change. Incidentally, this is ironic, since, from what you said, it was the new code/feature rockbox people inserted, with the bug, instead of just ported.


nope the bug was not inserted with pgn savingI did a little searching and originally there was just a port of gnuchess with the refenced bug then pgn saving was added which wwwrote to disk as you played that was changed to hold it in memory to decrease hard disk writes it just so happens it mad faulty assumptions about chessbox’s buffer which is pretty much the state of gnuchess v2. The next issue is AFAICT you only hit the end of the array after 120 moves (now 127) so really the game should already be over for all intents and purposes but we’ll let that slide


come to think of it i bet it is 60 moves and it takes a array entries per turn for each player so the original array was sized for the game constraints it just doesn’t happen to quit or even check it just starts overflowing so that would be another way to fix the bug but imo that kinda sucks


sorry thats ‘2’ array entries per turn and making the game bail at 60 moves would be another way to fix the bug

Ok. Question, doesn’t your 22:46 comment (”there is nary a sign of it [.pgn saving] in the GNUChess source”) contradict " the bug was not inserted with pgn saving”? I guess you are saying that the original rockbox pgn code worked.

Regardless, based on what you now wrote, the ideal solution would probably be to revert the code to how it was BEFORE some idiot decided to prevent disk writes. The motivation, I would guess, was probably because some older players have physical hard disks, but the number of people playing chess on those is small now since flash is used. Seriously the idea of wasting ram to hold the moves is asking for trouble since the number of moves can be arbitrarily high, 269, in chess and there is no fixed limit. Also the engine in weakest mode cannot be played in blitz, so we are talking about saving one write per minute, which isn’t needed even for physical hdd systems. So, based on what you wrote, I’d just revert it to post-pgn pre-ram-based-pgn-routine. However, in that case, the manuals should all be updated to ethically warn/notify people of the .pgn-saving feature.


if you want to get technical the game is supposed to end at 60 moves period.


and before you go throwing words like idiot around he was the same one who did th original pgn code and remember there are plenty of ipods still even if that isnt what you use to play chess

Well, not exactly. As I understand, mpeccorini uploaded a working pgn patch like I proposed above. It wasn’t accepted immediately, however. Instead, linuxstb asked mpeccorini, on irc, “Looking at your chessbox patch on Flyspray, am I right in thinking you are constantly writing to the disk?” mpeccorini didn’t apparently reply, but later asked about how much ram was in these players. I think he got an answer that is larger than normal for most players. He then wrote a different patch code that stored the entire game’s pgn in ram, which caused the problem. This ram-heavy/buggy patch was committed instead of the first one at . I am extremely thankful for mpeccorini’s work, but I can’t agree with linuxstb’s implication because even tiny hdds can write many times a second and we are talking about once per minute or so. Ideally, I am arguing mpeccorini should have pushed back, but in the existing world power structure, nobody dares do that because the reward to risk isn’t normally worth it. It is sort of interesting, I guess, and the bug’s history and is now fully solved.

Regardless, in light of the patch sitting there, I again think the ideal thing would probably be try to revert to his original patch, mostly since the code is already written. But, since there may be disagreement on that, just disabling pgn is certainly acceptable as well, and since that is done I guess we can close this.

linuxstb’s question was certainly apt for all other rockbox games, like goban, where moves are much quicker, and one can’t blame anyone for asking a question.


Available keyboard shortcuts


Task Details

Task Editing