public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Jon TURNEY <jon.turney@dronecode.org.uk> To: cygwin-xfree@cygwin.com Cc: matt@codespunk.com 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: <51C0F5DA.8010104@dronecode.org.uk> (raw) In-Reply-To: <51BE32B4.7020309@codespunk.com> [-- 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. -- Jon TURNEY 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); XFlush(d); sleep(1); } 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); XFlush(d); sleep(1); // 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); assert(buffer3); buffer2[0] = 0x3000; buffer2[1] = 0x3000; test(buffer3, propsize); while(1) XNextEvent(d, &e); } [-- Attachment #3: Type: text/plain, Size: 223 bytes --] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=51C0F5DA.8010104@dronecode.org.uk \ --to=jon.turney@dronecode.org.uk \ --cc=cygwin-xfree@cygwin.com \ --cc=matt@codespunk.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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).