X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By:	sourceware.org
X-Forefront-Antispam-Report:	CIP:132.245.2.21;KIP:(null);UIP:(null);IPV:NLI;H:BN1PRD0512HT004.namprd05.prod.outlook.com;RD:none;EFVD:NLI
X-SpamScore:	2
X-BigFish:	PS2(zzbb2dI98dI9371I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhb412mz32i2a8h668h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h1155h)
Message-ID:	<50F6F69F.3040000@coverity.com>
Date:	Wed, 16 Jan 2013 13:51:11 -0500
From:	Tom Honermann <thonermann AT coverity DOT com>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version:	1.0
To:	<cygwin AT cygwin DOT com>
Subject:	Re: Intermittent failures with ctrl-c
References:	<20121222175041 DOT GA14475 AT ednor DOT casa DOT cgf DOT cx> <20121223165621 DOT GA9935 AT ednor DOT casa DOT cgf DOT cx> <50DCB454 DOT 9030400 AT coverity DOT com> <20121229215725 DOT GA18847 AT ednor DOT casa DOT cgf DOT cx> <50E23F98 DOT 1060004 AT coverity DOT com> <20130101053606 DOT GB18911 AT ednor DOT casa DOT cgf DOT cx> <50E48743 DOT 5040401 AT coverity DOT com> <20130102204821 DOT GA6524 AT ednor DOT casa DOT cgf DOT cx> <50E4A597 DOT 1060600 AT coverity DOT com> <50F5D559 DOT 4090909 AT coverity DOT com> <20130116020420 DOT GA13284 AT ednor DOT casa DOT cgf DOT cx> <50F6D757 DOT 3000005 AT coverity DOT com> <50F6DB0F DOT 2020602 AT gmail DOT com> <50F6E695 DOT 20302 AT coverity DOT com> <CA+sc5mng_tHVwtzrPBexggCRzTWanNWEHBY0mfP43KhXZgrA=A AT mail DOT gmail DOT com>
In-Reply-To:	<CA+sc5mng_tHVwtzrPBexggCRzTWanNWEHBY0mfP43KhXZgrA=A@mail.gmail.com>
X-OriginatorOrg:	coverity.com
X-IsSubscribed:	yes
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

On 01/16/2013 01:05 PM, Earnie Boyd wrote:
> On Wed, Jan 16, 2013 at 12:42 PM, Tom Honermann <thonermann AT coverity DOT com> wrote:
>> On 01/16/2013 11:53 AM, marco atzeri wrote:
>>>
>>> On 1/16/2013 5:37 PM, Tom Honermann wrote:
>>>
>>>>
>>>> 4) Launch mintty using an existing Cygwin installation.  Naturally, this
>>>> will run a shell from the existing Cygwin install.
>>>>
>>>> 5) Change directories to the usr/bin directory of the snapshot.
>>>>
>>>
>>> This will cause a cygwin1.dll collision between the two versions
>>> Nothing is guarantee to work fine
>>
>>
>> Can you elaborate?  Cygwin supports multiple installations just fine these
>> days.  Use of a .bat file (an intervening cmd.exe process) should isolate
>> the environments for this test.
>>
>
> While you can multiple installations you cannot mix the environments.
> You did not copy mintty so you started it in one instance and then
> went to another instance which will cause a clash of resources.

Can you elaborate on what resources you are referring to?  I fail to see 
how the Cygwin binaries run via the .bat file could conflict with mintty 
(or the top level bash process) since the intervening cmd.exe execution 
would have blocked inheritance of Cygwin related resources, primarily 
since fork() isn't used to create these child processes.

My understanding is that shared Cygwin resources are keyed off of the 
location of the cygwin1.dll loaded into the Cygwin process.  If two 
Cygwin processes run with different cygwin1.dll instances, they should 
not share resources.  I can see a case for there being a problem if a 
Cygwin process creates another Cygwin process via fork() and that child 
process is run with a different cygwin1.dll instance, but that isn't the 
case here.  The only other case I can think of would require Cygwin 
looking at the process tree (stepping up through non-Cygwin processes) 
to get at resources.  That would be quite expensive on Windows.

>> Regardless, I was also able to produce a hang in bash running the same .bat
>> file from a cmd.exe prompt using only the snapshot install and the copied
>> bash.exe, false.exe, and dependent binaries - no mintty.  The hung bash.exe
>> process eventually timed out with an error message:
>>
>> 5 [unknown (0x176C)] bash 2000 sig_send: wait for sig_complete event failed,
>> signal 6, rc 258, Win32 error 0
>
> Looking at the list of DLL you copied you may still be seeing a
> conflict with which DLL is in use.

I don't see how that would be the case.  If it were, then it would not 
be possible (in general) to have multiple Cygwin installations with 
unrelated processes running concurrently from each installation.

> Do you see a hang if you remain in
> usr/bin and not changing directories to your copied files?

I believe that would be equivalent to testing in my (non-snapshot) 
Cygwin installation.  The goal is to test the snapshot.

Tom.


--
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 -