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.
_______________________________________________ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
