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: List-Archive: List-Help: , Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Message-Id: <3.0.5.32.19990805120829.00d46a90@pop.ma.ultranet.com> X-Sender: lhall AT pop DOT ma DOT ultranet DOT com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 05 Aug 1999 12:08:29 -0400 To: Chris Faylor From: "Larry Hall (RFK Partners, Inc)" Subject: Re: ntsec: patch 9 Cc: Corinna Vinschen , cygdev In-Reply-To: <19990805120512.A1187@cygnus.com> References: <3 DOT 0 DOT 5 DOT 32 DOT 19990805120034 DOT 00d4dd70 AT pop DOT ma DOT ultranet DOT com> <19990805113216 DOT A973 AT cygnus DOT com> <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> <19990805114512 DOT A1014 AT cygnus DOT com> <3 DOT 0 DOT 5 DOT 32 DOT 19990805120034 DOT 00d4dd70 AT pop DOT ma DOT ultranet DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 AT cygnus DOT com >>>>http://www.cygnus.com/ >>> >>>-- >>>cgf AT cygnus DOT com >>>http://www.cygnus.com/ >>> >>> > >-- >cgf AT cygnus DOT com >http://www.cygnus.com/ > >