Re: Intermittent failures with ctrl-c

[Tom Honermann <thonermann at coverity dot com>]

On 01/16/2013 01:05 PM, Earnie Boyd wrote:
> On Wed, Jan 16, 2013 at 12:42 PM, Tom Honermann <thonermann@coverity.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