Bug#883707: ace-freecell crashes on KDE desktops

2018-03-02 Thread Markus Koschany


Am 27.02.2018 um 20:29 schrieb Esa Peuha:
> I think I've found out what is causing this bug and why it only affects
> freecell. 
[...]

Thank you very much for the analysis, insight and your patch! I can
confirm that works for me. I agree this is probably a bug in xwin/kde or
at least an oddity. It's not worth the time to investigate further. I
will upload a new revision of ace-of-penguins with your patch soon.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#883707: ace-freecell crashes on KDE desktops

2018-02-27 Thread Esa Peuha
I think I've found out what is causing this bug and why it only affects
freecell. When any of these games start up, the kde window manager sends
an expose event for one pixel at the top left corner, then an expose
event for the rest of the top row of pixels, then an expose event for
the remaining pixel rows. This unusual pattern makes no difference for
the other games, because their top row of pixels contains just empty
background. However freecell puts all of its initially empty card stacks
right at the top of its window, and to make these stacks visible to the
player, each of them has the "empty" picture on them. Therefore when
freecell gets the initial one-pixel expose event, that pixel happens to
be in the leftmost empty stack, so it has to draw the "empty" picture
there. In the process of doing so, function build_image in xwin.c calls
XGetImage to get an 8x8 pixel square from the top left corner of the
window as an ximage so that it can pass the depth, format and bitmap_pad
parameters to XCreateImage. Unfortunately at that point freecell hasn't
written anything (even the background color) to 255 of the 256 pixels
because they haven't been exposed yet, and (as far as I can tell) if
*no other program* has done so either, those pixels are uninitialized
and the call to XGetImage fails; at least that seems to be why freecell
starts to work after starting and quitting any other of these games.

I don't know whether the actual bug is in xwin.c or kde (or both), and
I don't think I want to dig deeper to find out. However, it should be
easy to work around the problem in freecell by moving the tops of the
empty stacks to the second row of pixels; here's a patch to do that.
Could you try it to make sure it works?
--- freecell.c~ 2015-06-08 16:15:20.771400783 +0300
+++ freecell.c  2018-02-27 19:47:05.272651935 +0200
@@ -71,10 +71,10 @@
 
   for (s=0; s<4; s++)
   {
-freecells[s] = stack_create(s*W, 0);
+freecells[s] = stack_create(s*W, 1);
 stack_set_empty_picture(freecells[s], empty);
 
-outcells[s] = stack_create(4*W+9*M+s*W, 0);
+outcells[s] = stack_create(4*W+9*M+s*W, 1);
 stack_set_empty_picture(outcells[s], empty);
   }
 


Bug#883707: ace-freecell crashes on KDE desktops

2018-02-13 Thread Markus Koschany
Am 12.02.2018 um 22:34 schrieb Esa Peuha:
> That's very odd. Presumably a program can only cause that error message
> by calling XGetImage, and freecell (like every other of these games
> except taipei) can only do so from line 819 of xwin.c in build_image.
> However, the only non-constant arguments to XGetImage are display and
> window, and if one of those variables has an invalid value, I would
> expect an error long before reaching that point. Looking at the sources,
> the only obvious difference between freecell and everything else is that
> freecell defaults to a window that is 640 pixels wide and 480 pixels
> high, and I can just about imagine that some piece of code might treat
> a window with those exact dimensions specially. That should be easy to
> test; if "ace-freecell -width 700 -height 500" works when it would fail
> without those arguments, and if the other games fail if you start them
> with "-width 640 -height 480" then it's pretty clear this is the cause.

Thank you very much for the detailed response. I have tried the above
but ace-freecell would still fail with any variation of -width and
-height options. The other games start fine with -width 640 and -height 480.

This only happens when I try to start ace-freecell for the first time.
If I try to start the game again it suddenly works. Maybe the code
should be changed so that it not defaults to 640 x 480 pixels and
behaves like the other games?






signature.asc
Description: OpenPGP digital signature


Bug#883707: ace-freecell crashes on KDE desktops

2018-02-12 Thread Esa Peuha
That's very odd. Presumably a program can only cause that error message
by calling XGetImage, and freecell (like every other of these games
except taipei) can only do so from line 819 of xwin.c in build_image.
However, the only non-constant arguments to XGetImage are display and
window, and if one of those variables has an invalid value, I would
expect an error long before reaching that point. Looking at the sources,
the only obvious difference between freecell and everything else is that
freecell defaults to a window that is 640 pixels wide and 480 pixels
high, and I can just about imagine that some piece of code might treat
a window with those exact dimensions specially. That should be easy to
test; if "ace-freecell -width 700 -height 500" works when it would fail
without those arguments, and if the other games fail if you start them
with "-width 640 -height 480" then it's pretty clear this is the cause.



Bug#883707: ace-freecell crashes on KDE desktops

2018-02-11 Thread Markus Koschany
Hello Esa,

you were the last upstream contact for ace-of-penguins hence I would
like to forward a Debian bug report to you. I can confirm that
ace-freecell cannot be started on KDE desktops. The error message is:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  73 (X_GetImage)
  Serial number of failed request:  25
  Current serial number in output stream:  25

Interestingly the other games work and when I run one of them first and
then try to start ace-freecell, the game works without any issues as well.

So there might be some missing initialization in ace-freecell which the
other games do correctly or maybe it is something completely different.
I can reproduce this behavior only on KDE, so it might also be some kind
of KDE bug.

Do you have any ideas how this issue can be fixed?

Regards,

Markus