> 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 [email protected] https://lists.gnu.org/mailman/listinfo/bug-xboard
