www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/08/06/00:00:56

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
Message-ID: <19990805235940.B15572@ba.best.com>
Date: Thu, 5 Aug 1999 23:59:40 -0400
From: Glenn Spell <glenn AT gs DOT fay DOT nc DOT us>
To: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Problems with get_signal_mutex
Mail-Followup-To: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
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
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 <glenn AT gs DOT fay DOT nc DOT us>      )   _       _____
 )   Fayetteville, North Carolina, U. S. A.   )_ (__\____o /_/_ |
 )  _  _  _  _  _  _  _  _  _  _  _  _  _  _  )   >-----._/_/__]>
 )- blue skies - happy trails - sweet dreams -)             `0  |

- Raw text -


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