[Top][All Lists]

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

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

From: Vincent Legout
Subject: Re: [Bug-XBoard] [bug #31756] crash resizing engine window
Date: Fri, 3 Dec 2010 20:34:33 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Dec 03, 2010 at 10:47:30AM +0100, h.g. muller wrote :
> 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.

That's exactly what happens.

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

This bug also occurs for the "Move History" window, so I guess the crash
is due to Xaw3d.

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

Thanks for your explanations, I'll build XBoard without Xaw3d.


reply via email to

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