This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ntsec: patch 9


Not that I can determine.  There's really no tools there that are build 
related.  Mostly things like less, groff, man, and ncurses.  I've been
trying to rebuild these and as I do, it doesn't seem to affect what I
see one way or the other.  Also, I notice that man and (I think) things
that use pipes (tar ztvf blah.tar.gz | more) hang, which may or may not
be the same problem!;-)

Larry


At 12:05 PM 8/5/99 -0400, Chris Faylor wrote:
>Is there any possibility that the old apps are getting called along with the new
>ones in the scenario where you're seeing this error/
>
>-chris
>
>On Thu, Aug 05, 1999 at 12:00:34PM -0400, Larry Hall (RFK Partners, Inc) wrote:
>>Actually, I do have an old DLL to replace the cygwinb19.dll for apps I
>>haven't updated (I'm in the process of trying to do that now).  Its called
>>cygwinb19.dll though, so it seems like there shouldn't be a problem with
>>the wrong DLL being picked up.  Do you think it would help to copy the 
>>new DLL to that name though?
>>
>>Larry
>>
>>
>>At 11:45 AM 8/5/99 -0400, Chris Faylor wrote:
>>>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@cygnus.com
>>>>http://www.cygnus.com/
>>>
>>>-- 
>>>cgf@cygnus.com
>>>http://www.cygnus.com/
>>>
>>>
>
>-- 
>cgf@cygnus.com
>http://www.cygnus.com/
>
>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]