H.G.Muller wrote:Looks like it has crashed, and is just doing random things. If it gets stuck in an event handler, all new events will be queued, so the user interface would seem totally dead. Is it using CPU in this state?
I could not reproduce it, no matter how many pieces I dragged off board in Edit Position mode. Is it possible for you to create a stack dump so we can see where it gets stuck by killing it with a signal?
H.G.Muller wrote:Perhaps the best approach is to put a printf statement in the main event loop (while(1) gtk_main_iteration(); , in xboard.c). This loop should process events one by one. This at least should tell us if events are still noticed (and somehow not properly handled), or, if not, what the last event is that was handled.
H.G.Muller wrote:OK, so the problem is either that mouse events do not get handled, or that for some reason the plot library no longer performs the tasks the handler orders it to do. I suspect the latter; this can be easily confirmed by putting printfs in the routines LeftClick and RightClick in backend.c.
There are several levels at which this can go wrong. XBoard draws on a memory bitmap in response to mouse events or engine input, and expose events then copy the exposed area to the display. XBoard fakes the expose events when it alters the image. The bitmaps are allocated by resizing events, by destroying the old one, and creating a new one, and requesting a redraw of whatever it contained (such as a board with altered square size).
What happens when you resize the board window in this situation? It would in particular be interesting to see if this only hits the board widget, or the entire drawing system. For this it would be helpful if you could also display a logo, by setting -logoSize to non-zero and supplying some -firstLogo/-secondLogo. And open the Eval Graph window. Then you could see if any of those would still redraw at a new size when you size their window.
Users browsing this forum: No registered users and 2 guests