Strange coredump in new zsh-3.0.1 on Sunos4.1.3

Strange coredump in new zsh-3.0.1 on Sunos4.1.3

[C. v. Stuckrad]

Hi!

I yesterday tried to install the new 3.0.1 including the two patches
from the zsh-workers-list (Subjects: '4 bugs' + 'strange behaviour of autocd')
compiled on SunOS 4.1.3 with gcc 2.7.2.                   Then:

ONE zsh was fine (freshly logged in)
on top of 'screen' no zhsh would survive (vers. 3.0.0 does though).
and I get a coredump always at places like VARIABLE=`program` 
The places divver, I cud not find a 'real' system in the dumps,
but ALWAYS it's inside the initialisation files, and always at
an definition of a Variable. One stacktrace of gdb follows here:
-------------------- snip ---------------------------
GDB 4.11 (sparc-sun-sunos4.1.3),
Copyright 1993 Free Software Foundation, Inc...
Core was generated by `zsh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.1.8...done.
Reading symbols from /usr/lib/libdl.so.1.0...done.
#0  0x6fe4c in zclose (fd=19) at utils.c:921
921             while (!fdtable[max_zsh_fd])
(gdb) where
#0  0x6fe4c in zclose (fd=19) at utils.c:921
#1  0x25a2c in getoutput (cmd=0xce334 "/usr/local/etc/dotpath", qt=1)
    at exec.c:2051
#2  0x63764 in stringsubst (list=0xdbc40, node=0xdbc48, ssub=4) at subst.c:164
#3  0x62f2c in prefork (list=0xdbc40, flags=7) at subst.c:72
#4  0x217bc in addvars (l=0xce494, export=0) at exec.c:1070
#5  0x2253c in execcmd (cmd=0xce464, input=0, output=0, how=2, last1=2)
    at exec.c:1253
#6  0x2055c in execpline2 (pline=0xce4c0, how=2, input=0, output=0, last1=0)
    at exec.c:801
#7  0x1fa6c in execpline (l=0xce450, how=2, last1=0) at exec.c:647
#8  0x1f524 in execlist (list=0xce4d0, dont_change_job=1, exiting=0)
    at exec.c:527
#9  0x4c600 in execif (cmd=0xcda30) at loop.c:265
#10 0x23de8 in execcmd (cmd=0xcda30, input=0, output=0, how=2, last1=2)
    at exec.c:1606
#11 0x2055c in execpline2 (pline=0xce658, how=2, input=0, output=0, last1=0)
    at exec.c:801
#12 0x1fa6c in execpline (l=0xcda1c, how=2, last1=0) at exec.c:647
#13 0x1f524 in execlist (list=0xce668, dont_change_job=1, exiting=0)
    at exec.c:527
#14 0x4c600 in execif (cmd=0xccf20) at loop.c:265
#15 0x23de8 in execcmd (cmd=0xccf20, input=0, output=0, how=2, last1=2)
    at exec.c:1606
#16 0x2055c in execpline2 (pline=0xdb828, how=2, input=0, output=0, last1=0)
    at exec.c:801
#17 0x1fa6c in execpline (l=0xccf0c, how=2, last1=0) at exec.c:647
#18 0x1f524 in execlist (list=0xdb838, dont_change_job=0, exiting=0)
    at exec.c:527
#19 0x3e6c4 in loop (toplevel=0) at init.c:126
#20 0x40c8c in source (s=0xefffecb8 "/Vol/petzval_h1/stucki/.zsh/.zshenv")
    at init.c:803
#21 0x40e70 in sourcehome (s=0x406b0 ".zshenv") at init.c:840
#22 0x408c0 in run_init_scripts () at init.c:721
#23 0x3e3e4 in main (argc=4, argv=0xeffff204) at init.c:69
(gdb)
----------------------------- snip ---------------------------------

Any ideas ?  The (nearly) same setup on Solaris2.4 works so far !
How shall I debug this further ? The zsh is compiled WITH zsh-mem
and all debugging included, but did not tell something.

Clueless, Stucki


Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /

Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)

[C. v. Stuckrad]

Opps, sorry, I forgot the Value of the Variable :-))

On Sat, 2 Nov 1996, C. v. Stuckrad wrote:

> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libc.so.1.8...done.
> Reading symbols from /usr/lib/libdl.so.1.0...done.
> #0  0x6fe4c in zclose (fd=19) at utils.c:921
> 921             while (!fdtable[max_zsh_fd])
(gdb) p max_zsh_fd
$1 = 16777234
     ^ ^ ^ ^  OUTCH !?!?!?!?
(gdb) p fdtable
$2 = '\000' <repeats 17 times>, "\001\001"

Well, this explains the coredump, but WHY ?

On linux the version 3.0.1 works too :-)

Your's  Stucki


Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /

Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)

[Bart Schaefer]

On Nov 2,  4:30pm, C. v. Stuckrad wrote:
} Subject: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (2)
}
} On Sat, 2 Nov 1996, C. v. Stuckrad wrote:
} 
} > Program terminated with signal 11, Segmentation fault.
} > #0  0x6fe4c in zclose (fd=19) at utils.c:921
} > 921             while (!fdtable[max_zsh_fd])
} (gdb) p max_zsh_fd
} $1 = 16777234
}      ^ ^ ^ ^  OUTCH !?!?!?!?
} (gdb) p fdtable
} $2 = '\000' <repeats 17 times>, "\001\001"
} 
} Well, this explains the coredump, but WHY ?

zsh is picking an arbitrary value of 20 for the OPEN_MAX constant.  If
zclose() is being called on fd=19, chances are that at some previous
time the fdtable[] array was overflowed and trampled on max_zsh_fd.

Chances are further that the reason for this is that `screen' is leaving
way too many file descriptors open when it forks off children.  This is
actually a potential security problem, because a program written to expect
this behavior might obtain access to a pseudo-tty that it was not supposed
to be able to access.

I seem to recall patching at least one version of `screen' to close down
file descriptors when forking children, but that was years ago; I very
seldom use `screen' any more since it became gnuware (no, not *because*
it did), and I quit hacking on it even before that.

As the comment in system.h says, OPEN_MAX should be getting set by doing
a query of the OS at run time.  You should try to get a fixed screen, but
you should also try compiling with a larger OPEN_MAX (around 64 for SunOS,
I think) and see if that solves the problem.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3

[Zoltan Hidvegi]

> 
> Hi!
> 
> I yesterday tried to install the new 3.0.1 including the two patches
> from the zsh-workers-list (Subjects: '4 bugs' + 'strange behaviour of autocd')
> compiled on SunOS 4.1.3 with gcc 2.7.2.                   Then:
> 
> ONE zsh was fine (freshly logged in)
> on top of 'screen' no zhsh would survive (vers. 3.0.0 does though).
> and I get a coredump always at places like VARIABLE=`program` 
> The places divver, I cud not find a 'real' system in the dumps,
> but ALWAYS it's inside the initialisation files, and always at
> an definition of a Variable. One stacktrace of gdb follows here:

You may try this patch.  It fixes an obvious bug which was already present
in zsh-3.0.0 so it does not explain why zsh-3.0.0 worked.

Zoltan

*** Src/utils.c	1996/10/30 23:41:58	3.1.0.0
--- Src/utils.c	1996/11/02 22:15:19
***************
*** 913,919 ****
  {
      if (fd >= 0) {
  	fdtable[fd] = 0;
! 	while (!fdtable[max_zsh_fd])
  	    max_zsh_fd--;
  	if (fd == coprocin)
  	    coprocin = -1;
--- 913,919 ----
  {
      if (fd >= 0) {
  	fdtable[fd] = 0;
! 	while (max_zsh_fd > 0 && !fdtable[max_zsh_fd])
  	    max_zsh_fd--;
  	if (fd == coprocin)
  	    coprocin = -1;

Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)

[C. v. Stuckrad]

On Sat, 2 Nov 1996, Bart Schaefer wrote:

> zsh is picking an arbitrary value of 20 for the OPEN_MAX constant.  If
> zclose() is being called on fd=19, chances are that at some previous
> time the fdtable[] array was overflowed and trampled on max_zsh_fd.
> 
> Chances are further that the reason for this is that `screen' is leaving
> way too many file descriptors open when it forks off children.  This is
> actually a potential security problem, because a program written to expect
> this behavior might obtain access to a pseudo-tty that it was not supposed
> to be able to access.
> 
> I seem to recall patching at least one version of `screen' to close down
> file descriptors when forking children, but that was years ago; I very
> seldom use `screen' any more since it became gnuware (no, not *because*
> it did), and I quit hacking on it even before that.

OK, setting OPEN_MAX to 64 (and applying Zoltan's fix too)
did get rid of the bug. 

Thanks a lot !

BUT, it might be something totally different than I thought, NOT 'screen'
but 'ssh' (sshd), The secure-shell- programs from Tatu Ylonen
do open and pass on a filedescriptor to all their descendants.

This filedescriptor is 'constructed' by a test-program, and seems to
somehow get a definite number. And I saw this descriptor being the LAST
POSSIBLE Number (64!).

Our 'screen' is patched to NEVER close this descriptor (knowing it's
Number by an environment variable). Before this patch screen did close
nearly all descriptors (specially the needed one :-)

So zsh on screen on sshd might have died on that ...

For now your repair seems to have worked, and I wait for the users to
complain with now problems :-))

Thanks a lot,   sincerely your's     Stucki

Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /

Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)

[Bart Schaefer]

On Nov 3,  4:37pm, C. v. Stuckrad wrote:
} Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)
}
} OK, setting OPEN_MAX to 64 (and applying Zoltan's fix too)
} did get rid of the bug. 

I'd be curious to know if you tried the two fixes separately.  I don't
see how decrementing max_zsh_fd below zero in that loop could possibly
change it to 16777234 ( == (1<<24)+18, which is a lot of decrements);
but taking the bytes in 16777234 as an array of chars (char fdtable[])
yields "\01\0\0\021" which looks suspiciously like what you'd get if
you started with max_zsh_fd == 18 and stuffed 1 into the first byte.

} BUT, it might be something totally different than I thought, NOT 'screen'
} but 'ssh' (sshd), The secure-shell- programs from Tatu Ylonen
} do open and pass on a filedescriptor to all their descendants.
} 
} This filedescriptor is 'constructed' by a test-program, and seems to
} somehow get a definite number. And I saw this descriptor being the LAST
} POSSIBLE Number (64!).

That shouldn't be a problem, and in fact the reason it shouldn't be one
is *because* it's the last possible descriptor; zsh should never find
out that it exists, because open/dup/etc. should always return the lowest
available descriptor (which should be something between 3 and 63).  The
fdtable[] only includes descriptors that zsh itself has opened.

} So zsh on screen on sshd might have died on that ...

Easy enough to test; run the unpatched zsh under ssh without screen, and
then under screen without ssh.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)

[Zoltan Hidvegi]

> On Nov 3,  4:37pm, C. v. Stuckrad wrote:
> } Subject: Re: Strange coredump in new zsh-3.0.1 on Sunos4.1.3 (FIXED)
> }
> } OK, setting OPEN_MAX to 64 (and applying Zoltan's fix too)
> } did get rid of the bug. 
> 
> I'd be curious to know if you tried the two fixes separately.  I don't
> see how decrementing max_zsh_fd below zero in that loop could possibly
> change it to 16777234 ( == (1<<24)+18, which is a lot of decrements);
> but taking the bytes in 16777234 as an array of chars (char fdtable[])
> yields "\01\0\0\021" which looks suspiciously like what you'd get if
> you started with max_zsh_fd == 18 and stuffed 1 into the first byte.

I guess that the problem is that due to the incorrect OPEN_MAX value an
fdtable[OPEN_MAX] = 1 assignment happens somewhere.  max_zsh_fd comes right
after the fdtable array so this assignment overwrites the first byte of
max_zsh_fd.  On big endian machines like the sparc this causes exactly the
described problem.  My bugfix has nothing to do with that.  That bug I
fixed probably can never cause any real problems (it's been there for a
while now and noone noticed that) since max_zsh_fd decrements stop at the
first non-zero byte and max_zsh_fd is never used for writing.

Zoltan