Winboard Forum

I have encountered this on rare occasions playing. Xboard enters some mode, apparently expecting some odd input, and I can't do anything. Even File|New Game doesn't exit this mode. It seems to happen when I drag pieces off the board then release, but not always. It's made me lose every time it happens.

Lately, I've been using edit position, and now I regularly experience the same problem. It's really irritating as I get a position mostly set up, then bam, it hits and I have to restart and begin again. Below is an example image. I think I was dragging off the upper left rook off when it hit. You can see a small matrix in the a8 square. This happens every time, and always on a8. The line into square a7, happened when I was trying random ways to exit, clicking the mouse, trying to drag, etc. Perhaps you can tell me what's happening, as the status text doesn't indicate any special mode. ESC and other obvious ways to exit are not effective.

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: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?

It's not using the CPU, no. I guess I need assistance creating a stack dump. I can kill all three signals I have tried. Ctrl-C works. no stack dump that I'm aware of.

I can also build it with debugging if needed, and run with -debug. Haven't done that yet. It is weird I can't describe how to duplicate it because it really is caused by dragging pieces off, but I can't figure out what may be different when it hits. In any event, I don't have much trouble duplicating it even if I can't figure out the exact cause.

I'm not running an exact version from git. The only change is related to the target circles. I like circles that are 1/4 or 1/5 instead of 1/2 the square size.

That it is not using CPU makes the hypothesis that it is stuck in an event handler less likely. It is hard to see what could keep the event handler from returning if it isn't looping. (Reading from stdin would do it, but it should never do that anywhere.)

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

Not knowing what to print, I just issued "here\n". It doesn't seem to be related to this loop, as once the issue happens, I keep seeing more "here" messages in the terminal window. But that makes sense. I suspect otherwise, it wouldn't be able to respond to File|Quit, which it does. Just you can't select or move pieces about.

Switching to machine white, it does actually play a move, I think. I can hear it, the little matrix on a8 changes, and the clock countdown switches to black. But I see no movement on the main board, and can't select anything to continue the game. BTW, I switched to 4.9.1 without alterations.

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.

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.

Ok, progress. Resizing allows me to continue normally until it hits again.

LeftClick events continue when this happens. I didn't put checks into RightClicks. I can still follow up with your logo/graph suggestions if needed, but I'm not a logo guy and thus don't have any.

Your mention of the way it is dawn makes me wonder if the small matrix on a8 is in fact the board, but warped in size, color, and texture due to some external factor when the issue manifests.

You are right! This is in fact the board. It seems like it has switched to a squareSize of 1x1 or 2x2 pixels. This makes it effectively insensitive to clicking, as translation of pointer coordinates to board squares will fall very far off board, and will then be ignored.

Determining a new square size happens in the routine Resize() in xboard.c, which is called through DragProc() via some timer delay (to defer the resizing of the board to after the user has stopped sizing the window) from window size or move events. I guess we should put a few print statements in ReSize(), to see how it arrives at this small squareSize through sqx,sqy and earlier w and h and the a.width and a.height of the various widgets.

It is still weird that dragging pieces would trigger a resizing event. This is supposed to happen only when you move or size the window. (And moving without sizing would make ReSize() exit without doing anything.)

CSI = Chess Scene Investigation