X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=G6hgQqrBqxbm7sppMAquJXUt9KZMniqGKPuGjIivv/B
	Gfvltr2b3fArb2Y76SDDBIEozm861FbXwPvRVzaUvhATru10o70vTxJvWNgS7Wxi
	6WjdVlg4UxwKiRHjStI6FXNLQ7dtMjiX1zHXud8v0qJTfld+nBmsNbBPXcvJH+/E
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=zVIlutnv0co5tgyGqYMBD/8ETOo=; b=Frd36dycbHHKtOaYr
	FuNEu8DSEef6crxy5BBPL61YdMzCpunO2+IFkOEIUNy0cz9KB9Lf49qwInD82wn+
	XgbQ7o3yknup6cYdx7luz42yqmbQT4THUBdbhiRCO67tWSgDOjp9o54Gom15Hsva
	TTtF9IxrpPdYWpUux3Tk2mpJ/Y=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO:	smtpout05.bt.lon5.cpcloud.co.uk
X-CTCH-RefID:	str=0001.0A090205.529E0D2F.0015,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
X-Junkmail-Premium-Raw:	score=27/97,refid=2.7.2:2013.10.9.131815:17:27.888,ip=86.174.32.56,rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, CT_TEXT_PLAIN_UTF8_CAPS, __CTE, __ANY_URI, URI_ENDS_IN_HTML, __URI_NO_MAILTO, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __URI_NS, SXL_IP_DYNAMIC[56.32.174.86.fur], HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_7000_LESS
X-CTCH-Spam:	Unknown
Message-ID:	<529E0D3B.8020505@dronecode.org.uk>
Date:	Tue, 03 Dec 2013 16:56:27 +0000
From:	Jon TURNEY <jon DOT turney AT dronecode DOT org DOT uk>
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: emacs-x11: new clipboard size limitation?
References:	<ac98a224051c2e59d2a1a0d455717531 AT mhoenicka DOT de> <529C8716 DOT 7020601 AT dronecode DOT org DOT uk> <20131202141740 DOT GC11800 AT calimero DOT vinschen DOT de> <529C9F81 DOT 5060900 AT dronecode DOT org DOT uk> <20131203103129 DOT GG11800 AT calimero DOT vinschen DOT de> <20131203112830 DOT GH11800 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20131203112830.GH11800@calimero.vinschen.de>

On 03/12/2013 11:28, Corinna Vinschen wrote:
> On Dec  3 11:31, Corinna Vinschen wrote:
>> On Dec  2 14:56, Jon TURNEY wrote:
>>> On 02/12/2013 14:17, Corinna Vinschen wrote:
>>>> On Dec  2 13:11, Jon TURNEY wrote:
>>>>> What you write does seem to support the theory that this is a regression in
>>>>> select() in the cygwin DLL.  It might be useful if you could say what version
>>>>> of the cygwin DLL you had when it was working correctly before you upgraded.
>>>>>
>>>>> [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html
>>>>> [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html
>>>>
>>>> Are you sure this is a select problem?  If so, can you create an STC,
>>>> perhaps?
>>>
>>> "Only a madman is absolutely sure".  I'm afraid the best test case I have a
>>> the moment is:
>>>
>>> Install xorg-server-debuginfo
>>> Start XWin -noclipboard -multiwindow
>>> Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it
>>> Start emacs-x11, open the Shakespeare text from [1] in a buffer
>>> Open notepad
>>> Copy and paste the text from the emacs buffer into notepad
>>> The breakpoint is hit.  Notice that select() has returned 0, the read ready
>>> fd_set is empty and the timeout hasn't expired. I claim that the read ready
>>> fd_set should indicate that the X connection socket is ready.
>>
>> Well, that's not exactly an STC...
>>
>> So, IIUC, you're saying that, in fact, select doesn't return too early,
>> rather it returns without setting the return value correctly.  You
>> expect it to return a value > 0, right?

Yes, I'm expecting it to return 1 with a bit set in the fd_set.

I'm not sure what it means to return before the timeout expires with value 0.

> I don't see any bigger changes in select since Cygwin 1.7.19.  Only one
> change since then, and that's only in 1.7.26, not in 1.7.25 as the OP
> claimed using.  The change in 1.7.19 is only 64 bit related, changing an
> unsigned to a size_t cast and a few debug printfs.  Only in 1.7.18 is a
> little bit bigger change but it should only affect signal handling.

Okay, so I did what I should have done in the first place and tried bisecting
through cygwin DLL versions for the past 6 months and they all behave the same
way.

Tried bisecting through the X server versions for the past 6 months, and it
seems that this problem first appears in X server 1.14.3-2

(As an aside, it's probably relevant to the recent discussion, that I can't
find the thread for, about how many previous versions we should keep around
that it's not possible to do this bisection without 'Secret Knowledge' at the
moment)

This does contain a few clipboard changes, and in particular it changes the
way the messages get processed so we will return to the select() more often
(after each stage of the conversion operation), which it looks like it could
be incorrect sometimes, but I'd expect this to cause unneeded blocking
(waiting in select() for a message which has already been placed on the event
queue by XPending() rather than the observed behaviour.

Anyhow, I guess I need to look at this some more...

> Talking about wndproc.c, it only checks iReturn for being < 0.  After
> that, we don't really know which value it has, we only know that
> FD_ISSET(iConnNumber, &fdsRead) returns 0.  The value of iReturn should
> be printed in the debug output at line 133.

It's 0 when I inspect it with the debugger, but yes, I'll change that.

> What kind of object is the iConnNumber descriptor?  Pipe?  Fifo?
> Socket?  /dev/windows?  We really need a simple testcase without the 
> X and emacs overhead...

It's a socket connected to the X server.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -