public inbox for
help / color / mirror / Atom feed
From: Jon TURNEY <>
Subject: Re: Cygwin/X crashes when combined with ssh/nx tunneling and -multiwindow
Date: Wed, 19 Jun 2013 00:05:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On 16/06/2013 22:48, Matt D. wrote:
>   > I've applied a fix to address the immediate problem of not checking
>   > for the failure, and I've uploaded a snapshot at [1]. Perhaps you
>   > could try that and see if it fixes the issue for you?
> Yes, this solves the crash problem (thank you!).
>   > I would also be interested to know how the icon for the window which
>   > was causing this issue appears.
> I've attached some screenshots of the taskbar and titlebar icons for Eclipse
> 4.2 using your XWin.exe build running with an without nx.
> The titlebar icon does NOT appear when running Eclipse with vanilla X. The
> taskbar icon also uses full colors; I do not know if it's a different icon or
> if nx is using some kind of compression.
> The second set of images (eclipse-4_2-nx_2 and eclipse-4_2-nonx_2) indicate
> the time of crash. When Eclipse starts up is displays a splash image which
> initially does not have an icon in its titlebar. Notably, a window border only
> appears when running Eclipse with nx. Despite not having a border, the icon is
> still relevant because it is the same one used to display in the taskbar.
> The crash occurs when the icon is being loaded onto the splash window. To
> reiterate, the window is NOT created with this icon. It is loaded sometime
> later while Eclipse is initializing.

Ah.  I was hoping you could use xprop to examine the _NET_WM_ICON property of
the window, but if it's a transient state that may not be practical.

I would guess that the difference in appearance between the nx and non-nx
cases is due to nx not transporting some window appearance hints.

>   > Hmm... this seems to indicate that icon was of size -1x-1, which
>   > doesn't seem right...
> Perhaps it has to do with the icon being applied after the window has already
> been created?
>   > From the backtrace, it looks like the crash is occurring due to a
>   > failure when converting the X11 icon to a Windows icon, and then not
>   > checking properly for that failure.
> It looked to me like the crash was occurring at line 264 of icon_convert.c; a
> memcpy to DIB_pixels which I believe was uninitialized. Regardless, the memcpy
> is one without verifying DIB_pixels or checking the return value of CreateBitmap.
> This is what I has planned to look into.. if I ever get XWin.exe to compile.

I did a bit more testing and managed to craft some malformed _NET_WM_ICON
properties which could crash the multiwindow mode WM in different ways (small
test case attached), so I've added another patch to do more validation of
_NET_WM_ICON data before it is used.

Volunteer Cygwin/X X Server maintainer

[-- Attachment #2: test-invalid-net-wm-icon.c --]
[-- Type: text/plain, Size: 1509 bytes --]

/* gcc test-invalid-net-wm-icon.c -o test-invalid-net-wm-icon -lX11 */

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

#include <X11/Xlib.h>

Display *d;
Window w;
Atom net_wm_icon;
Atom cardinal;

void test(unsigned int *buffer, unsigned int buffer_length)
  int length = buffer_length/sizeof(unsigned int);
  XChangeProperty(d, w, net_wm_icon, cardinal, 32,
                  PropModeReplace, (const unsigned char*) buffer, length);


int main(int argc, char **argv)
    /* Invalid _NET_WM_ICON icons */
    d = XOpenDisplay(0);
    int s = DefaultScreen(d);
    net_wm_icon = XInternAtom(d, "_NET_WM_ICON", False);
    cardinal = XInternAtom(d, "CARDINAL", False);
    XEvent e;
    w = XCreateWindow(d, RootWindow(d, s), 0, 0, 200, 200, 0,
                      CopyFromParent, InputOutput, CopyFromParent, 0, 0);

    XMapWindow(d, w);

    // sizes are just absurd
    unsigned int buffer[] = {-1, -1, 0xFFFFFFFF, 0xFFFFFFFF};
    test(buffer, sizeof(buffer));

    // property should be 256K, but is only 64K
    int propsize = 0x10000;
    unsigned int *buffer2 = malloc(propsize);
    buffer2[0] = 512;
    buffer2[1] = 512;
    test(buffer2, propsize);

    // property is absurdly large, but still not enough for icon
    propsize = 0x100000;
    unsigned int *buffer3 = malloc(propsize);
    buffer2[0] = 0x3000;
    buffer2[1] = 0x3000;
    test(buffer3, propsize);

    while(1) XNextEvent(d, &e);

[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

Unsubscribe info:
Problem reports:

      reply	other threads:[~2013-06-19  0:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-15 12:07 Matt D.
2013-06-15 23:38 ` Jon TURNEY
2013-06-16 21:48   ` Matt D.
2013-06-19  0:05     ` Jon TURNEY [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).