This may be related to a long-known bug that exists in both Scid and Scid vs
PC. If you are adding or deleting moves/variations in a complex game tree that
has a non-standard start and a FEN string with a 'fullmove number' other than
one, you're likely bumping up against this edge case.
Historically, this has been a very difficult segfault to reproduce. It sounds
like you've found a case that is easily replicated. Try changing the 'fullmove
number' in the FEN string (the last data field) to '1', give the game tree a
leading null move or two if necessary, and see if the problem goes away. If it
does, hunt that bug down and kill it!!!
On 7/24/20 3:34 AM, Fulvio Benini via Scid-users wrote:
Hi Greg,
thanks for the detailed analysis.
My guess is it doesn't depend on the engine but it is triggered when the
analyzed move is added to the current (probably complex) game.
It is pretty easy to debug SCID on Linux, something like:
sudo apt-get install build-essential gdb cmake tcl-dev
git clone https://git.code.sf.net/p/scid/code scid-code
cd scid-code
mkdir Debug && cd Debug
cmake .. -DCMAKE_BUILD_TYPE=Debug && make
gdb scid
That will give you the exact line where the buffer overflow happened and will
be of great help.
Bye,
Fulvio
Il 24/07/2020 02:39 Greg Marks <gtma...@gmail.com> ha scritto:
I've discovered what seems to be a workaround for the buffer overflow
problem I described in my June 23, 2020, message to this list.
This might hint at the source of the problem (or it might mean that
the problem is now moot).
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
