delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/08/05/11:49:25

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
<http://sourceware.cygnus.com/ml/#faqs>
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Thu, 5 Aug 1999 11:45:12 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: Corinna Vinschen <corinna AT vinschen DOT de>
Cc: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: ntsec: patch 9
Message-ID: <19990805114512.A1014@cygnus.com>
References: <37A8114F DOT 9101F2AE AT vinschen DOT de> <19990804214745 DOT A15316 AT cygnus DOT com> <37A9682E DOT EA185B11 AT vinschen DOT de> <19990805113216 DOT A973 AT cygnus DOT com>
Mime-Version: 1.0
X-Mailer: Mutt 0.95.6i
In-Reply-To: <19990805113216.A973@cygnus.com>; from Chris Faylor on Thu, Aug 05, 1999 at 11:32:16AM -0400

On reviewing the changes between 17-Jul and 26-Jul, the only thing that I see
that could affect anything is changes I made to detect multiple cygwin DLLs
being used.

You don't, by any chance, have more than one DLL in your path or on your system
do you?

-chris

On Thu, Aug 05, 1999 at 11:32:16AM -0400, Chris Faylor wrote:
>I am not seeing anything like this.  I've just done a couple of configure/make
>cycles with no problems.
>
>Do you have anything special in your CYGWIN environment variable?
>
>-chris
>
>On Thu, Aug 05, 1999 at 12:32:14PM +0200, Corinna Vinschen wrote:
>>Chris Faylor wrote:
>>> 
>>> Thanks.  Applied.
>>> 
>>> Does the new snapshot still fail for you when you issue the
>>> 'man tcsh' command?
>>> 
>>> cgf
>>
>>Hi Chris,
>>
>>unfortunately the answer is `yes'. I have found, that this behaviour
>>is not reproducable beyond winsup-990726!
>>
>>Notice, that this happens regardless of the ntsec setting.
>>
>>winsup-990726 itself shows the behaviour:
>>
>>	tcsh> man tcsh
>>
>>shows man page, then pressing `q' in `less' results in:
>>
>>	0 0 [main] D:\bin\sh.exe 1029 sig_send: error sending
>>	signal(-3) to pid 1029, Win32 error 6
>>
>>Error 6 is `illegal handle'.
>>
>>Since winsup-990801 it's worse than before:
>>
>>	tcsh> man tcsh
>>
>>... results in:
>>
>>	/usr/local/bin/groff: can't find `DESC' file
>>	/usr/local/bin/groff:fatal error: invalid device `ascii'
>>
>>... and after pressing `q':
>>
>>	0 0 [main] D:\bin\sh.exe 1029 sig_send: error sending
>>	signal(-3) to pid 1029, Win32 error 6
>>
>>If I try to run it with strace, I get the following on stderr:
>>
>>	strace.exe: couldn't get message length from subprocess,
>>	windows error 6
>>
>>If, for example, the complete winsup directory is up to date,
>>starting `make' results in:
>>
>>	make[1]: Entering directory `/src/cdkb21/winsup'
>>	Making all in regexp...
>>	make[2]: Entering directory `/src/cdkb21/winsup/regexp'
>>	make[2]: Nothing to be done for `all'.
>>	make[2]: Leaving directory `/src/cdkb21/winsup/regexp'
>>-->	 0 0 [main] D:\bin\sh.exe 1009 sig_send: error sending
>>	signal(-3) to pid 1009, Win32 error 6
>>	make[1]: Leaving directory `/src/cdkb21/winsup'
>>	make[1]: Entering directory `/src/cdkb21/winsup'
>>	Making all in mingw...
>>-->	 0 0 [main] D:\bin\sh.exe 1016 sig_send: error sending
>>	signal(-3) to pid 1016, Win32 error 6
>>	make[2]: Entering directory `/src/cdkb21/winsup/mingw'
>>	make[2]: Nothing to be done for `all'.
>>	make[2]: Leaving directory `/src/cdkb21/winsup/mingw'
>>	Making all in utils...
>>	make[2]: Entering directory `/src/cdkb21/winsup/utils'
>>	make[2]: Nothing to be done for `all'.
>>	make[2]: Leaving directory `/src/cdkb21/winsup/utils'
>>-->	 0 0 [main] D:\bin\sh.exe 1020 sig_send: error sending
>>	signal(-3) to pid 1020, Win32 error 6
>>	make[1]: Leaving directory `/src/cdkb21/winsup'
>>
>>Let's talk about what happens: It's in EVERY case /bin/sh, that
>>fails! In my environment, /bin/sh is bash. Regardless of the
>>circumstances, it's only bash, that produces this error.
>>If you look into the message, you will see, that it fails to
>>work on a handle that references the calling process itself.
>>
>>I have attached the strace output of the above `make' example. It was
>>compiled with -DDEBUGGING. I fear, it's not very useful because as
>>ever when I try to strace the phenomenon, I get:
>>
>>	strace.exe: couldn't get message length from subprocess,
>>	windows error 6
>>
>>Hopeful,
>>Corinna
>
>
>-- 
>cgf AT cygnus DOT com
>http://www.cygnus.com/

-- 
cgf AT cygnus DOT com
http://www.cygnus.com/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019