From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20667 invoked by alias); 28 Jul 2014 23:57:56 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 20651 invoked by uid 89); 28 Jul 2014 23:57:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPAM_BODY1 autolearn=no version=3.3.2 X-HELO: p3plsmtpa06-04.prod.phx3.secureserver.net Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (HELO p3plsmtpa06-04.prod.phx3.secureserver.net) (173.201.192.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Jul 2014 23:57:53 +0000 Received: from [10.0.1.110] ([72.209.18.161]) by p3plsmtpa06-04.prod.phx3.secureserver.net with id Xzxr1o0093UWwwg01zxrVy; Mon, 28 Jul 2014 16:57:52 -0700 Message-ID: <53D6E386.3060001@codespunk.com> Date: Mon, 28 Jul 2014 23:57:00 -0000 From: "Matt D." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: xinit hangs on XWin infinite loop when using -displayfd References: <53CC6789.4000601@codespunk.com> <53CD368C.3060509@codespunk.com> <53CD3917.4060305@codespunk.com> <53CD4E2C.6040204@codespunk.com> <53D6436D.2090808@dronecode.org.uk> In-Reply-To: <53D6436D.2090808@dronecode.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00025.txt.bz2 Doh! I was so blind! Windows XP does not have an IPv6 protocol installed by default. I added it and the problem went away. This sounds like a bug. XWin should verify whether a device which supports the target protocol exists before attempting to open a socket on it. What is this used for? Sharing a local X session with someone else? Logging onto an existing X session at work from home? I've only ever used X locally or through ssh forwarding. Matt D. On 7/28/2014 8:34 AM, Jon TURNEY wrote: > > Thanks for reporting this problem. > > On 21/07/2014 18:30, Matt D. wrote: >> I found as a workaround to add the arguments "-nolisten tcp" when >> invoking xinit. However, I was under the impression that it was >> incompatible with -multiwindow and -clipboard, both of which seem to be >> working fine: >> >> https://cygwin.com/ml/cygwin-xfree/2009-05/msg00016.html > > That restriction no longer exists. > > https://cygwin.com/ml/cygwin-xfree/2009-10/msg00007.html > >> On 7/21/2014 12:00 PM, Matt D. wrote: >>> Ok.. so I let xinit do its thing to see if it got anywhere. Eventually >>> it will pop and error box. Interestingly, I specified a displayfd value >>> of "3" and yet both the popup and the log are reporting "5": > > This is expected. xinit must know the display number of the X server it > starts, so it can pass it on to any clients it starts, so it has a patch > which should notice the -displayfd option, transparently use it to > determine the display number for any clients they start, and then pass > on the display number to the specified file descriptor > >>> My XWin.0.log is about 15MB of repeated attempts to open a socket. Here >>> is a snippet. I hope this helps: >>> >>> InitConnectionLimits: MaxClients = 255 >>> Welcome to the XWin X Server >>> Vendor: The Cygwin/X Project >>> Release: 1.15.1.0 >>> OS: CYGWIN_NT-5.1 matthew-17ffb52 1.7.30(0.272/5/3) 2014-05-23 10:36 >>> i686 >>> OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) >>> Snapshot: 20140709-git-2e9c13ea41c51df7 >>> >>> XWin was started with the following command line: >>> >>> X -displayfd 5 >>> >>> ddxProcessArgument - Initializing default screens >>> winInitializeScreenDefaults - primary monitor w 1062 h 703 >>> winInitializeScreenDefaults - native DPI x 96 y 96 >>> ddxProcessArgument - arg: -displayfd >>> Trying to create socket for display number 0 >>> _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 >>> _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:0 >>> _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 >>> >>> .. >>> Trying to create socket for display number 59534 >>> _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 >>> _XSERVTransOpen: transport open failed for inet6/matthew-17ffb52:59534 >>> _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 >>> (EE) Fatal server error: >>> (EE) Failed to find a socket to listen on(EE) >>> [ 58128.390] (EE) Server terminated with error (1). Closing log file. > > Ah. So, it seems that we have checked all ports from 6000 to 59534 + > 6000 = 65534 and decided they are no good because we can't open an ipv6 > socket. > > (It looks like there is another minor bug here in that we don't try port > 65535! :-)) > > I guess if you just run XWin, it reports that it can't create an inet6 > listener, but it continues anyway (unless the -nopn option is used). > > But, the implementation of -displayfd requires that creating all the > listener socket succeeds. (It's not clear that this should be changed, > otherwise we could reach the conclusion that it's ok to start a server > on display n with a limited set of protocols, when a server already > exists on display n with an non-intersecting set of protocols) > > So, you may find that -nolisten inet6, rather than -nolisten tcp (which > prevents both ipv4 and ipv6 listening) also works around the problem. > > You might want to also investigate why inet6 sockets can't be opened. > -- 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/