Menu
▾
▴
#266 scid 5.1 crash SIGABRT Treewindow
I'am using gentoo linux.
Scid 5.1 seemed to be working fine; lc0 worked, evrything worked.
Then I had to import a pgn-file into my biggest database, called bigbase; 5.57M games.
Then I wanted to use the Tree Window using bigbase. Scid crashed; SIGABRT.
Starting scid from the command-line and going to the same crash; resulted in
scid: /var/tmp/portage/games-board/scid-5.1.0/work/scid-5.1.0/src/position.cpp:1567: void Position::DoSimpleMove(const simpleMoveT&): Assertion `piece_Color(sm.capturedPiece) == enemy' failed.
Aborted (core dumped) scid
Trying the same in scid 4.7.0 didn't result in a crash. Looks like there
is some bug in generating a kind of index for the database in scid 5.1
That assert isn’t an “index-generation” failure in itself; it’s Scid aborting because it hit an impossible move while replaying moves into a position:
Meaning: Scid believes a move is a capture, but the piece it thinks is being captured is not an enemy piece at that square.
The crash you’re seeing is an assertion, and assertions are normally only enabled in debug (or assert-enabled) builds. In a “release” build this same condition would usually not abort the program; it might instead show up as incorrect behavior later (or be silently ignored), which is why this can look like a “Scid 5.1 bug” even though it may be triggered by a bad/undecodable game.
Also, when Scid opens a database it does not immediately read and validate every game’s movelist.
.si4/.si5(index).sn4/.sn5(names/players, etc.).sg4/.sg5and those are only read/decoded when a specific game is accessed (loaded for display, analysis, tree traversal that needs the actual move text, etc.).
So it’s possible for a database to “open fine” (because the index loads), and then later crash only when some feature causes Scid to actually decode moves from
.sg4/.sg5.One practical way to force Scid to decode every game (and thereby locate the faulty one) is to export the entire database to PGN. That export requires Scid to read and translate the moves for each game; if there is a corrupt/invalid game record, the export will typically fail or stop at/near the problematic game, letting you identify and remove/repair it.
In short: this is consistent with “one or more games in the
.sg4/.sg5are not decodable and the Tree window is just the first feature that happens to hit that game and triggers the assert in an assert-enabled build.Thank you for your fast reply and explanation.
Exporting to pgn didn't give any fails or stops. Opening that pgn-file in scid did give parsing errors for a number of games. I Deleted those games and used maintenance/compact database; opening the Tree Window gave the same problem and an abort.
I've compiled scid 5.1 myself in gentoo based on the ebuild for scid-5.0.2; so it is possible i'am using
an assert-enabled build.
Out of curiousity I've started scid 5.1 again and opened the pgn-file (the full database export). Using the pgn-file and then opening the Tree Window just worked. Perhaps this sheds more light on the issue.
Keep up the good work.
Thanks for the update. If you can confirm that after creating a new .si5 database and importing the big pgn-file, it works fine, we can safely assume the error was caused by some corrupt games.
It may also be worth mentioning that Chess960 games are supported only in SCID5 (.si5) and PGN databases. Older versions may fail to detect this variant and incorrectly attempt to import those games into SCID4 (.si4) databases.
Evrything seems to be working; after importing the big pgn-file into a new .si5 database. To me it
seems that .si5 has some improvements.
Chess960 games could well be the culprit; I update my database with TWIC and 960 is included in
those files. Scid4.7 doesn't seem to mind.
Improvements can at first be seen as a bug or an error; it is probably a good idea to convert my excisting databases using the pgn-method to the .si5 format.
Thanks.