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