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: <19990805235940.B15572@ba.best.com> Date: Thu, 5 Aug 1999 23:59:40 -0400 From: Glenn Spell To: cygdev Subject: Problems with get_signal_mutex Mail-Followup-To: cygdev References: <37AA0833 DOT 2EB7632D AT vinschen DOT de> <19990805182423 DOT A4366 AT cygnus DOT com> <19990805222033 DOT A5609 AT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990805222033.A5609@cygnus.com>; from "Chris Faylor" on Thu, Aug 05, 1999 at 10:20PM Organization: the aerie On 5 Aug 1999 around 10:20PM (-0400) Chris Faylor wrote: > On Thu, Aug 05, 1999 at 06:24:23PM -0400, Chris Faylor wrote: > > >On Thu, Aug 05, 1999 at 11:54:59PM +0200, Corinna Vinschen wrote: > >> > >>If CYGWIN is set to `tty' and you start a shell in a console > >>window, pressing Ctrl-C leads into a logout of the shell. I've been noticing this for a while. > >>Interesting: This is true only, if the shell is the process, that > >>opens the console window. If you start another shell in this > >>shell, the effect is not reproducable in the subshell. After > >>returning to the parent shell, it's reproducable again. That's not what happens here with Win95 text mounts. Using bash, continuously pressing Ctrl-C will lead to an exit after the tenth printing of "Use exit to leave the shell." This happens whether bash is the login shell or a subshell. If I move to other subshells and back, the condition is not remembered. Using sh (ash), in the login shell Ctrl-C will always return a prompt. In a subshell, behavior is irratic, but eventually (usually after one ot two Ctrl-C's) Ctrl-C will no longer seem to be accepted. If I move to other subshells and back, the condition is remembered. In a minute or two, the following message appears: $ $ ****** ../../../devo/winsup/exceptions.cc:505 __get_signal_mutex failed, res 258, Win32 error 288 ****** ../../../devo/winsup/exceptions.cc:505 __get_signal_mutex failed, res 258, Win32 error 288 0) function ../../../devo/winsup/syscalls.cc, line 184 $ /* that's with 99-06-27 snapshot */ $ $ ****** ../../../devo/winsup/exceptions.cc:492 __get_signal_mutex failed, res 258, Win32 error 288 0) function ../../../devo/winsup/syscalls.cc, line 190 /* with 99-07-17 snapshot */ $ $ uname -a CYGWIN_95-4.0 LOCALHOST 21.0 (0.14/1/2) 1999-7-18 00:13:28 i586 unknown $ exception.cc:492 switch (get_signal_mutex ()) /* in call_handler */ syscalls.cc:190 sig_protect (here, 1); /* in _read */ Win32 error 288 is Not Owner. 99-07-29 (1999-7-30 01:37:57) snapshot does not give the error message but the behavior is the same using sh as login shell. (Using bash as login shell all subshells automatically go into the background and have to be killed off with 'kill'.) With all more recent snapshots, including 99-08-04 (1999-8-5 18:18:02), the behavior is still the same as before, but no error messages. > Well, I don't know precisely how I broke it but it should be fixed > in the next snapshot. I'm following up because this behavior may be related to other reports. I can't check the new snapshot until tomorrow and although I expect different behavior from it, this info may be helpful. Regarding "get_signal_mutex", I get more than a screenfull (24 lines) of the following every time I start a bash that has been compiled with gcc-2.95. ****** ../../../src/winsup/exceptions.cc:348 __get_signal_mutex failed, res -1, Win32 error 6 ****** ../../../src/winsup/exceptions.cc:348 __get_signal_mutex failed, res -1, Win32 error 6 bash-2.03$ That particular printout was using the 99-06-14 snapshot. Here's the relevant line numbers in exceptions.cc... 346 set_process_mask (sigset_t newmask, int sync) 347 { 348 (void) get_signal_mutex (); According to that marvelous tool, Insight, this happens before bash starts running the main() function (or whatever it's called). (I've not figured out how to display the cygwin1.dll source with Insight. I even compiled cygwin with a different base and changed the name of the dll. With gdb, I seemed to be able to load symbols and such from more than one file, but not with Insight. Yes, cygwin was compiled with '-ggdb -gstabs'. Well, I could display the cygwin source, but not at the same time that the bash executable was loaded to run.) I compiled winsup with gcc-2.95 to get a Cygwin library compiled with gcc-2.95, then re-compiled gcc-2.95, then re-compiled bash... same thing. This happens using any cygwin1.dll that I can find. This may be related to what Corinna reported in the "ntsec: patch 9" thread: ------------pasted from another thread---------------- 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'. -----------------end of paste----------------------- I'll check the new snapshot tomorrow with all the above. -glenn -- ) Glenn Spell ) _ _____ ) Fayetteville, North Carolina, U. S. A. )_ (__\____o /_/_ | ) _ _ _ _ _ _ _ _ _ _ _ _ _ _ ) >-----._/_/__]> )- blue skies - happy trails - sweet dreams -) `0 |