public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: "Matt D." <matt@codespunk.com>
To: cygwin-xfree@cygwin.com
Subject: Re: xinit hangs on XWin infinite loop when using -displayfd
Date: Mon, 28 Jul 2014 23:57:00 -0000	[thread overview]
Message-ID: <53D6E386.3060001@codespunk.com> (raw)
In-Reply-To: <53D6436D.2090808@dronecode.org.uk>

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/


  reply	other threads:[~2014-07-28 23:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21  1:06 Matt D.
2014-07-21 15:49 ` Matt D.
2014-07-21 16:00   ` Matt D.
2014-07-21 17:30     ` Matt D.
2014-07-28 12:35       ` Jon TURNEY
2014-07-28 23:57         ` Matt D. [this message]
2014-08-04 15:57           ` Jon TURNEY

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=53D6E386.3060001@codespunk.com \
    --to=matt@codespunk.com \
    --cc=cygwin-xfree@cygwin.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: 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).