While I am able to stop the clock occasionally by moving the board, it
doesn't happen often. It is much easier to reproduce by iconifying/
deiconifying the board window.
I have not been able to reproduce this (since I fixed the earlier bug of
not clearing the pending timeout when it occurred). What exactly are the
conditions under which you observe this? (which board size, which
windows open, which mode). I tried in two-machines mode, with the Move
list open, clicking on the taskbar to iconify. (Other windows have their
own icon, and don't react. Only the Move List is enslaved to the main
window.) I also cannot find anything suspect in the code.
If I cannot reproduce it, the only hope to debug it is if Byrial trie it
himself. A good method would be to put a printf at every place where
there is an XtAppAddTimeOut or XtRemoveTimeOut call, printing the timer
XID, and one in the callback routine to see if the event actually occurs
(and for which timer XID). This is how I found the previous bug in this
area. Just try until the clock stops, and then look if there was a clock
timeout pending which simply never occurred (which would be an X11 bug),
or if the timeout is erroneously removed by some other event.