bug-xboard
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-XBoard] [bug #31756] crash resizing engine window


From: h.g. muller
Subject: Re: [Bug-XBoard] [bug #31756] crash resizing engine window
Date: Fri, 03 Dec 2010 10:47:30 +0100

At 18:10 2-12-2010 +0000, Vincent Legout wrote:
A bug has been reported in Debian. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604610

I thought that it is fixed in the development version, but I was wrong, I can
reproduce it with the latest git. It only happens when xboard is built with
xaw3d enabled.

Ah, this explains why I could never reproduce that bug... :-)

I don't think this is our bug, though. Resizing of windows is done by the
windows manager, or the Xaw library. We don't have any callbacks on
that window that would be triggered on resize, so none of our code is
activewhen the crash occurs. The window consists of only a few simple
standard widgets: two text edits and a few label widgets.

Last week in the Dutch Open in Leiden someone using XBoard showed
me some very sick behavior here (in an attempt to provoke the crash).
He did not succeed in making in crash, but while he was doing this
the window was in two-pane mode. Normally the panes for both
engines should be equally large. As the upper-most top and lower-most
bottom of the text edits are chained to the window edges, and the middle
is not chained (which should leave it at the default XtRubber setting),
they should always stay equal in height. However, when repeatedly
resizing the window vertically, one pane was growing w.r.t. the other,
until it covered more than 75% of the window area, and the other has
almost shrunk to nothing.

According to the specs this should not be possible. Xaw3d is just sick.

Now it could be that an actual crash only occurs when the window is
in single-pane mode. (Could someone please test this hypothesis?)
It is true that XBoard uses an un usual trick in this mode, as the two
panes are always there, but the upper one is resized such that it
pushes the lower one out of view. I don't think the specs forbid this,
however, and with plain Xaw it works like a charm.

So my guess is that the crash is due to the Xaw3d bug that manifests
itself in disproportional resizing of the individual panes, which at some
point creates an impossible value (like negative height for the lower,
out-of-view pane), which makes Xaw3d choke.

So it seems Xaw3d needs fixing, and there is little we can do about it.
Just don't build with Xaw3d. Unless the board size is very large Xaw3d
looks very ugly anyway.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]