4.0.1: problem with sourcing on Solaris

4.0.1: problem with sourcing on Solaris

[Jos Backus]

taiko:/depot/src/zsh-4.0.1% cat x                     
a=`uname -s`
taiko:/depot/src/zsh-4.0.1% uname -s
SunOS
taiko:/depot/src/zsh-4.0.1% truss -f -o out Src/zsh -f
taiko% . ./x
[hangs][press ^C]
taiko% exit

Relevant section of truss output:

29085:  write(1, " S u n O S\n", 6)                     = 6
29084:  read(12, " S u n O S\n", 5120)                  = 6
29085:  _exit(0)
29084:  read(12, 0x000F734C, 5120)                      = 0
29084:  llseek(12, 0, SEEK_CUR)                         Err#29 ESPIPE
29084:  close(12)                                       = 0
29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  kill(29085, SIG#0)                              = 0
29084:      Received signal #18, SIGCLD, in sigsuspend() [caught]
29084:        siginfo: SIGCLD CLD_EXITED pid=29085 status=0x0000
29084:  sigsuspend(0xFFBEF000)                          Err#4 EINTR
29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  sigprocmask(SIG_SETMASK, 0xFFBEEBD8, 0xFFBEEB48) = 0
29084:  waitid(P_ALL, 0, 0xFFBEEAE8, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
29084:  times(0x000DAB38)                               = 932283769
29084:  waitid(P_ALL, 0, 0xFFBEEAE8, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) Err#10 E
CHILD
29084:  setcontext(0xFFBEECE8)
29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  kill(29085, SIG#0)                              Err#3 ESRCH
29084:  kill(29085, SIGCONT)                            Err#3 ESRCH
29084:  sigsuspend(0xFFBEF000)          (sleeping...)
29084:      Received signal #2, SIGINT, in sigsuspend() [caught]
29084:  sigsuspend(0xFFBEF000)                          Err#4 EINTR

Anyone else seen this?

-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: 4.0.1: problem with sourcing on Solaris

[Peter Stephenson]

Jos Backus wrote:
> taiko:/depot/src/zsh-4.0.1% cat x                     
> a=`uname -s`
> taiko:/depot/src/zsh-4.0.1% uname -s
> SunOS
> taiko:/depot/src/zsh-4.0.1% truss -f -o out Src/zsh -f
> taiko% . ./x
> [hangs][press ^C]
> taiko% exit

I don't get this.

> Relevant section of truss output:
> ...
> 29084:  setcontext(0xFFBEECE8)
> 29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
> 29084:  kill(29085, SIG#0)                              Err#3 ESRCH
> 29084:  kill(29085, SIGCONT)                            Err#3 ESRCH
                      ^^^^^^^
In particular, this is missing from my output.  Could /etc/zshenv have
anything to do with it?  Or there could be a race --- there are a couple of
cases where zsh will send an explicit SIGCONT, in particular a whole set in
jobs.c.  Or it could be a red herring, to do with you interrupting it, and
the real problem is earlier.

> 29084:  sigsuspend(0xFFBEF000)          (sleeping...)
> 29084:      Received signal #2, SIGINT, in sigsuspend() [caught]
> 29084:  sigsuspend(0xFFBEF000)                          Err#4 EINTR

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: 4.0.1: problem with sourcing on Solaris

[Jos Backus]

Here's a clue: for some reason, after re-running configure (because I changed a
couple of entries in config.modules), BROKEN_KILL_ESRCH got define'd. When
defined, I see the problem; when I undefine BROKEN_KILL_ESRCH (the default),
the shell works fine. I'm wondering how this could end up being define'd...

On Tue, Jun 05, 2001 at 06:11:04AM +0000, Bart Schaefer wrote:
> } 29084:      Received signal #2, SIGINT, in sigsuspend() [caught]
> } 29084:  sigsuspend(0xFFBEF000)                          Err#4 EINTR
> 
> It would have been nice to see what came after that, but my guess is
> that `errflag' became true and we exited the loop that way.  The real
> question still is, why didn't we see the ESRCH error from kill(pid, 0)?

29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  sigprocmask(SIG_SETMASK, 0xFFBEEBD8, 0xFFBEEB48) = 0
29084:  setcontext(0xFFBEECE8)
29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  sigprocmask(SIG_UNBLOCK, 0x000DABE0, 0x000DABFC) = 0
29084:  llseek(11, 0, SEEK_CUR)                         = 13
29084:  close(11)                                       = 0
29084:  sigprocmask(SIG_BLOCK, 0x000DABE0, 0x000DABFC)  = 0
29084:  sigprocmask(SIG_UNBLOCK, 0x000DABE0, 0x000DABFC) = 0
29084:  ioctl(10, TIOCGSID, 0xFFBEF964)                 = 0
29084:  getsid(0)                                       = 9149
29084:  ioctl(10, TIOCSPGRP, 0xFFBEFA10)                = 0
29084:  fstat64(0, 0xFFBEF988)                          = 0
29084:  fcntl(0, F_GETFL, 0x00000000)                   = 2
29084:  fstat64(0, 0xFFBEF820)                          = 0
29084:  time()                                          = 991690436
29084:  time()                                          = 991690436
29084:  sigaction(SIGINT, 0xFFBEF988, 0x00000000)       = 0
29084:  sigaction(SIGINT, 0xFFBEF5E0, 0x00000000)       = 0
29084:  getuid()                                        = 3387 [3387]
29084:  ioctl(10, FIONREAD, 0xFFBEF644)                 = 0
29084:  ioctl(10, TIOCGSID, 0xFFBEF50C)                 = 0
29084:  getsid(0)                                       = 9149
29084:  ioctl(10, TIOCSPGRP, 0xFFBEF5B8)                = 0
29084:  ioctl(10, TCSETSW, 0xFFBEF648)                  = 0
29084:  write(10, "\r1B [ m1B [ m1B [ m1B [".., 20)     = 20
29084:  write(10, "1B [ K", 3)                          = 3
29084:  read(10, 0xFFBEF4CB, 1)         (sleeping...)
29084:  read(10, "04", 1)                               = 1
29084:  write(10, "\r\n", 2)                            = 2
29084:  alarm(0)                                        = 0
29084:  ioctl(10, TCSETSW, 0x000DAB04)                  = 0
29084:  getpid()                                        = 29084 [29083]
29084:  llseek(0, 0, SEEK_CUR)                          = 6483602
29084:  _exit(1)

Thanks,
-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: 4.0.1: problem with sourcing on Solaris

[Bart Schaefer]

On Jun 5,  2:16pm, Jos Backus wrote:
} Subject: Re: 4.0.1: problem with sourcing on Solaris
}
} Here's a clue: for some reason, after re-running configure (because
} I changed a couple of entries in config.modules), BROKEN_KILL_ESRCH
} got define'd. When defined, I see the problem; when I undefine
} BROKEN_KILL_ESRCH (the default), the shell works fine. I'm wondering
} how this could end up being define'd...

It could end up being defined because the configure test for it is bad.

    pid=getpid() + 10000;
    ret=kill(pid, 0);

If a process whose PID is 10000 more than the current PID happens to be
running, then the test returns the wrong result.

Also, if getpid() returns a sufficiently large number, pid + 10000 might
be larger than the largest possible PID, causing a (legitimate) EINVAL,
or might wrap to negative and be interpreted as a pgrp.

The ideal solution would be to fork(), wait(), and then kill(), but the
vagaries of doing a proper wait() portably are such that it may be too
messy to use in a configure test.  So I suggest the following; it tries
at least 15 different PIDs (and no more than 23 of them) and concludes
BROKEN_KILL_ESRCH only if none of those give ESRCH.

The & 0xffffff is just because I'm paranoid that left-shifting a negative
number might do sign extension, causing an infinite loop.  Maybe that's
not really an issue, but it's a handy way to limit the number of shifts
as well.

Index: zshconfig.ac
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/zshconfig.ac,v
retrieving revision 1.1
diff -c -r1.1 zshconfig.ac
--- zshconfig.ac	2001/06/08 03:53:13	1.1
+++ zshconfig.ac	2001/06/08 04:43:12
@@ -1377,10 +1377,9 @@
 #include <errno.h>
 main()
 {
-    int pid, ret;
-    pid=getpid() + 10000;
-    ret=kill(pid, 0);
-    exit(ret<0 && errno!=ESRCH);
+    int pid = (getpid() + 10000) & 0xffffff;
+    while (pid && (kill(pid, 0) == 0 || errno != ESRCH)) pid >>= 1;
+    exit(errno!=ESRCH);
 }
 ],
   zsh_cv_sys_killesrch=yes,

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: 4.0.1: problem with sourcing on Solaris

[Jos Backus]

On Fri, Jun 08, 2001 at 04:50:27AM +0000, Bart Schaefer wrote:
> On Jun 5,  2:16pm, Jos Backus wrote:
> } BROKEN_KILL_ESRCH (the default), the shell works fine. I'm wondering
> } how this could end up being define'd...
> 
> It could end up being defined because the configure test for it is bad.

I thought the configure test looked kind of too simple. Good catch Bart.

-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;