The clock stops if the board window is moved with stickyWindows on

[Byrial Jensen]

If I move the board window during a game while the stickyWindows option
is actice, the clock for the player who has the move will most often -
but not always - stop. The same happens if the window is iconified and
deiconified.

I tried to find the reason but failed. But I made the following 2
observations:

1) The window actions will trigger the function DelayedDrag() if
stickyWindows is active, and DelayedDrag() uses XtAppAddTimeOut() like
also the clock does. Could it really be that no more than one timer can
be active?

2) The function ClockTimerRunning() is defined, but never called. I
suppose it should be deleted.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g.muller]

>If I move the board window during a game while the stickyWindows option is
>actice, the clock for the player who has the move will most often - but
>not always - stop.

Yes, I can reproduce that in Two-Machines mode.

>The same happens if the window is iconified and deiconified.
>
>I tried to find the reason but failed. But I made the following 2
>observations:
>
>1) The window actions will trigger the function DelayedDrag() if
>stickyWindows is active, and DelayedDrag() uses XtAppAddTimeOut() like
>also the clock does. Could it really be that no more than one timer can be
>active?

I am pretty sure that is not the case. ScheduleDeayedEvent uses
XtAppAddTimeOut, and some scheduled events (e.g. for the -keepAlive option)
also run in parallel with the clock. And I remember that for some delays I
could not use ScheduleDelayedEvent because it would erase another event.
(ScheduleDelayedEvent can indeed only be used once.) These then started to
work without problems when I made them call XtAppAddTimeOut directly.
Finally, like you say, the clock does not always stop, while in a clocked
game there should always be one clock-tick event pending.

So it seems we unreliably lose events or commands from/to the X-server. I
guess this could in principle be caused by improper XSync or XSynchronize
calls: it seems the second argument of those can cause clearing of the
event queue?


>2) The function ClockTimerRunning() is defined, but never called. I
>suppose it should be deleted.

I guess we could. But it small, and you never know if it could be useful in
the future. So why bother.


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Arun Persaud]

Hi

>> 2) The function ClockTimerRunning() is defined, but never called. I
>> suppose it should be deleted.
>
> I guess we could. But it small, and you never know if it could be useful
> in the future. So why bother.

I would say cleaning up the code is always a good thing... if you need
it later you can still get it back easily by looking at old git versions.

cheers
        ARUN

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g.muller]

>I would say cleaning up the code is always a good thing... if you need
>it later you can still get it back easily by looking at old git versions.

Indeed, but deleting a 1-statement unused but potentially useful function
is the least of our concerns in that respect. Now that 4.6.0 is released,
it might be a good time for a major code overhaul in master. Perhaps we
should still wait for this until after the major bugs in 4.6.0 are fixed.
There already were a number of complaints in reaction to the 4.6.0 release,
so I guess it would be a good idea to release a 4.6.1 not too long after it,
with all the fixes. What I fixed so far is:

1) In XBoard the splitting of a path-name of an engine obtained through
browsing
    in the Load Engine dialog into an -fcp engine command and an -fd directory
    does not work, because Linux refuses to execute plain filenames in the
current
    directory, but insists they must be prefixed with ./
2) In WinBoard file browsing for a save file in the Tournament Options
dialog did
    not allow you to type a not-yet-existing file name.
3) It was impossible for people in the new EditPosition mode -pieceMenu false
     to guess how they should clear the board without reading the manual.
4) The transition to -ncp mode for people that referenced a non-existing engine
     (basically those not having installed fairymax) was not entirely
smooth, and
     involved waiting out the engine feature time-out of 10 sec while the
UI was frozen.
5) The clock problem noticed by Byrial.

The first four are already fixed in master. I will cherry-pick them into
v4.6.x later,
because I already pushed some new stuff to master that is not mature enough
to qualify for 4.6.1.

As for a code cleanup, it might be good to split off some reasonably
self-contained
parts from backend.c, which is really getting awkwardly big. I was thinking
about
the following split:

ics.c: all the stuff directly related to -ics mode (receive_from_ics,
parse_board12 etc.)
engine.c: the basic stuff for using an engine (HandleMachineMove,
InitChessProgram)
match.c: stuff for loading engines and running tournaments
usermove.c: high-level mouse handler (LeftClick, RightClick)
pgnsearch.c: stuff for loading game files, and searching positions in them

For porting XBoard to Android, it seems also useful to extensively refactor
the
X11 front-end, basically bleeding it dry for any sharable code. I already
made some
preliminary attempts for that in my hgmaster branch, but I will probably
redo it in a
cleaner way, drawing on that experience. In any case it means that all
X11-independent
code will be cleansed from xoptions.c, which will then only contain
GenericPopup(),
and a number of wrappers to access control elements in it. The rest (all dialog
description tables and dialog-specific callbacks) will go to a new file
dialogs.c.

 From xboard.c I will extract the menu descriptor table and overall menu logic,
(leaving only wrappers for creating menus and menu items) and relocate it
to a new
file menus.c. This could mean I will change the .xresource interface, which now
can define X-translations for zillions of 'MenuProcs', like 'FlipViewProc',
where it would
code-wise be really far more efficient and portable to specify that as
'MenuItem(Flip View)',
where a single X-specific routine 'MenuItem' would take care of all, and
the item name
is passed on to it as a string (i.e. in a portable format, that can be
related to the
back-end action from the menu tables by platform-independent user code.)
And the board-drawing logic will be moved to a new file board.c, leaving
only a
DrawSquare(piece, squarecolor, inscription, inscriptionPlacement) wrapper
in xboard.c.


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g.muller]

OK, I fixed the clock problem. Turned out there can be multiple timer
events pending, but the same few event IDs are reused all the time. And
DelayedDrag would always clear the timeout for previous Drag event, even if
that event had already taken place, and was now in use for the clock.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Byrial Jensen]

Den 16-03-2012 14:58, h.g. muller skrev:
> OK, I fixed the clock problem. Turned out there can be multiple timer
> events pending, but the same few event IDs are reused all the time. And
> DelayedDrag would always clear the timeout for previous Drag event, even
> if that event had already taken place, and was now in use for the clock.

I have tried the fix, and it much reduces the problem with the clock
stopping. But I can still in some cases get the clock to stop if I move
the board around for several seconds.

After playing at FICS for some time I got a segfault. This is the stack
backtrace made from the core file:

#0  0x00007f5b68139694 in XtRemoveTimeOut () from
/usr/lib/x86_64-linux-gnu/libXt.so.6
#1  0x000000000045e5b3 in DelayedDrag ()
#2  0x000000000045e634 in EventProc ()
#3  0x00007f5b6812e076 in XtDispatchEventToWidget () from
/usr/lib/x86_64-linux-gnu/libXt.so.6
#4  0x00007f5b6812e5d4 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
#5  0x00007f5b6812e8c4 in XtDispatchEvent () from
/usr/lib/x86_64-linux-gnu/libXt.so.6
#6  0x00007f5b6812ed6b in XtAppMainLoop () from
/usr/lib/x86_64-linux-gnu/libXt.so.6
#7  0x0000000000457a89 in main ()

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g.muller]

> After playing at FICS for some time I got a segfault. This is the stack
> backtrace made from the core file:
>
> #0  0x00007f5b68139694 in XtRemoveTimeOut () from

Hmm, this is going to be hard. One can argue that a segfault in this Xt
routine must always be an X11 bug. I am pretty sure that when called from
DelayedDrag, it can never be called with an argument that at least at some
time was a valid timer-event ID. It could be that the event has already
fired or was removed. But especially the former case seems impossible to
guard against, so the routine should never crash on that.

It could be we have the opposite problem as before, ScheduleDelayedEvent
removing a timer-event that has already fired and was reused by
DelayedDrag, so that when DelayedDrag finally wants to remove it, it is no
longer valid. I will check all usage of XtRemoveTimeOut for consistency.
But if I don't find anything there, I am at a loss.

X11 is suspect anyway. I got a report from someone, that double-clicking
on a text-input field would segfault XBoard (he mentioned the Load Engine
dialog, but as this is done by GenericPopup I expect the same in almost
every dialog). He showed the stack trace, (
http://www.talkchess.com/forum/viewtopic.php?t=42834&postdays=0&postorder=asc&topic_view=&start=36
), and there wasn't a single routine of ours in there. All Xaw/Xt stuff
trying to set the text selection in reaction to the mouse click.
Presumably in the second click, as doing two single clicks did never cause
the error for him. We do define a translation for text widgets (assigning
another X-action), but only for keystrokes, not for mouse clicks.

As I cannot reproduce this error, I can't debug anything. Perhaps you can
check if it occurs for you?


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Byrial Jensen]

Den 17-03-2012 08:13, h.g.muller@... skrev:

>> After playing at FICS for some time I got a segfault. This is the stack
>> backtrace made from the core file:
>>
>> #0  0x00007f5b68139694 in XtRemoveTimeOut () from
>
> Hmm, this is going to be hard. One can argue that a segfault in this Xt
> routine must always be an X11 bug. I am pretty sure that when called from
> DelayedDrag, it can never be called with an argument that at least at some
> time was a valid timer-event ID. It could be that the event has already
> fired or was removed. But especially the former case seems impossible to
> guard against, so the routine should never crash on that.
>
> It could be we have the opposite problem as before, ScheduleDelayedEvent
> removing a timer-event that has already fired and was reused by
> DelayedDrag, so that when DelayedDrag finally wants to remove it, it is no
> longer valid. I will check all usage of XtRemoveTimeOut for consistency.
> But if I don't find anything there, I am at a loss.

Note that I got the coredump while connected to FICS, and I that now can
only reproduce the clock-stop-while-moving-board on FICS. I cannot any
longer get the clock to stop while playing an engine.

Does ICS mode use any timers, which engine mode doesn't?

> X11 is suspect anyway. I got a report from someone, that double-clicking
> on a text-input field would segfault XBoard (he mentioned the Load Engine
> dialog, but as this is done by GenericPopup I expect the same in almost
> every dialog). He showed the stack trace, (
> http://www.talkchess.com/forum/viewtopic.php?t=42834&postdays=0&postorder=asc&topic_view=&start=36
> ), and there wasn't a single routine of ours in there. All Xaw/Xt stuff
> trying to set the text selection in reaction to the mouse click.
> Presumably in the second click, as doing two single clicks did never cause
> the error for him. We do define a translation for text widgets (assigning
> another X-action), but only for keystrokes, not for mouse clicks.
>
> As I cannot reproduce this error, I can't debug anything. Perhaps you can
> check if it occurs for you?

Stack trace from the forum message referenced above:

#0  0xb7749424 in __kernel_vsyscall ()
#1  0x00c26fa0 in raise () from /lib/libc.so.6
#2  0x00c288b1 in abort () from /lib/libc.so.6
#3  0x00c5debb in __libc_message () from /lib/libc.so.6
#4  0x00ce2ce1 in __chk_fail () from /lib/libc.so.6
#5  0x00ce34bc in __wctomb_chk () from /lib/libc.so.6
#6  0x4bc9b227 in _Xaw_iswalnum () from /usr/lib/libXaw.so.7
#7  0x4bc6e128 in ?? () from /usr/lib/libXaw.so.7
#8  0x4bc85f26 in XawTextSourceScan () from /usr/lib/libXaw.so.7
#9  0x4bc82b70 in _XawTextAlterSelection () from /usr/lib/libXaw.so.7
#10 0x4bc900e3 in ?? () from /usr/lib/libXaw.so.7
#11 0x022f3371 in ?? () from /usr/lib/libXt.so.6
#12 0x022f374a in ?? () from /usr/lib/libXt.so.6
#13 0x022f3d44 in _XtTranslateEvent () from /usr/lib/libXt.so.6
#14 0x022cb615 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6
#15 0x022cbd9a in ?? () from /usr/lib/libXt.so.6
#16 0x022cac77 in XtDispatchEvent () from /usr/lib/libXt.so.6
#17 0x022cae2c in XtAppMainLoop () from /usr/lib/libXt.so.6
#18 0x080969e8 in main ()

I can certainly not reproduce this.

As I see it, it is not X that fails, but the glibc standard function
wctomb() (wchar to multibyte conversion) which fails an internal check
for a buffer length and aborts the program.

I can suspect some kind of system installation problem.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Byrial Jensen]

Den 17-03-2012 14:31, Byrial Jensen skrev:
> Note that I got the coredump while connected to FICS, and I that now can
> only reproduce the clock-stop-while-moving-board on FICS. I cannot any
> longer get the clock to stop while playing an engine.
>
> Does ICS mode use any timers, which engine mode doesn't?

I did some more testing with the current master branch code. I have been
able to stop the clock now while playing an engine, so it is not an ICS
mode only thing.

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.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g.muller]

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

[Byrial Jensen]

Den 29-03-2012 23:41, h.g. muller skrev:

>
>> 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.

I  cannot reproduce this any longer after I have upgraded to Ubuntu
12.04. It might have been caused by a faulty installation.

_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
https://lists.gnu.org/mailman/listinfo/bug-xboard