Re: [Bug-XBoard] The clock stops if the board window is moved with stickyWindows on

[Byrial Jensen]

Den 17-03-2012 08:13, address@hidden 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.