zsh seg fault when TERM = linux

zsh seg fault when TERM = linux

[Murilo Opsfelder Araújo]

Hi zsh workers,

I'd like to report a situation for you.

I'm trying to connect in a ssh server with a user using zsh as your
default shell but zsh crashes.

In following, there are some info. If you need more, please, feel free to ask.

TERM env var on client side is set to 'linux':

client$ echo $TERM
linux

On the server I changed the user's shell to csh:

server$ echo $SHELL
/bin/csh

When logged in on server I tried to run zsh:

server$ zsh
Segmentation fault
Exit 139

I tried a gdb with zsh. See the results:

server$ gdb zsh
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging
symbols found)...
(gdb) run
Starting program: /usr/local/bin/zsh
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x283784bd in strlen () from /lib/libc.so.7
(gdb) bt
#0  0x283784bd in strlen () from /lib/libc.so.7
#1  0x282f600e in cgetset () from /lib/libc.so.7
#2  0x282f64f2 in cgetent () from /lib/libc.so.7
#3  0x2824940e in _nc_read_termcap_entry () from /lib/libncursesw.so.7
#4  0x2826accf in _nc_read_entry () from /lib/libncursesw.so.7
#5  0x28268d47 in _nc_setupterm () from /lib/libncursesw.so.7
#6  0x2823d928 in tgetent () from /lib/libncursesw.so.7
#7  0x0807bd29 in init_term ()
#8  0x0809593b in setstrvalue ()
#9  0x08099ba7 in assignsparam ()
#10 0x0809ab3e in createparamtable ()
#11 0x0807b9df in setupvals ()
#12 0x0807d6ce in zsh_main ()
#13 0x08052e32 in main ()
(gdb)

Does gdb seem to be OK?

To resolve the problem I rollbacked user's shell to zsh on server side
and did a env TERM=xterm on client side. See:

client$ env TERM=xterm ssh remoteuser@server
Password: *******
server$

So, I don't know if this situation is a bug or a conf problem. Feel
free to ask more information.

Thanks in advance.

-- 
Murilo Opsfelder Araujo
mopsfelder@gmail.com
{murilo,panda}@bsd.com.br
BSD will never die.
"Tempo difícil esse em que estamos, em que é mais fácil quebrar um
átomo do que um preconceito." - Albert Einstein

Re: zsh seg fault when TERM = linux

[Peter Stephenson]

=?ISO-8859-1?Q?Murilo_Opsfelder_Ara=FAjo?= wrote:
> TERM env var on client side is set to 'linux':
> 
> server$ gdb zsh
> (gdb) bt
> #0  0x283784bd in strlen () from /lib/libc.so.7
> #1  0x282f600e in cgetset () from /lib/libc.so.7
> #2  0x282f64f2 in cgetent () from /lib/libc.so.7
> #3  0x2824940e in _nc_read_termcap_entry () from /lib/libncursesw.so.7
> #4  0x2826accf in _nc_read_entry () from /lib/libncursesw.so.7
> #5  0x28268d47 in _nc_setupterm () from /lib/libncursesw.so.7
> #6  0x2823d928 in tgetent () from /lib/libncursesw.so.7
> #7  0x0807bd29 in init_term ()
> #8  0x0809593b in setstrvalue ()
> #9  0x08099ba7 in assignsparam ()
> #10 0x0809ab3e in createparamtable ()
> #11 0x0807b9df in setupvals ()
> #12 0x0807d6ce in zsh_main ()
> #13 0x08052e32 in main ()
> (gdb)
> 
> Does gdb seem to be OK?

Yes, the backtrace makes sense.  However, the crash is down inside the
library code, where zsh calls tgetent().  The shell simply passes down
the terminal name, i.e. the string "linux", and maybe a buffer.  It's
going through calls to ncursesw and libc, which is correct.

Do you have the configuration for this version of zsh?  Can you see if
the option TGETENT_ACCEPTS_NULL is #define'd in config.h?  It should be
under Linux, but if it wasn't it might be that the 2048-byte buffer was
too short.  If the option is set, it's hard to see how the shell could
be causing this.  Indeed, I see in the manual page for tgetent that the
buffer pointer is ignored, although it wasn't specially about ncursesw.

Can you post the output of "infocmp -C linux" on the system where it's
crashing?

Thanks.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: zsh seg fault when TERM = linux

[Murilo Opsfelder Araújo]

On Thu, Apr 30, 2009 at 10:54 AM, Peter Stephenson <pws@csr.com> wrote:
> =?ISO-8859-1?Q?Murilo_Opsfelder_Ara=FAjo?= wrote:
>> TERM env var on client side is set to 'linux':
>>
>> server$ gdb zsh
>> (gdb) bt
>> #0  0x283784bd in strlen () from /lib/libc.so.7
>> #1  0x282f600e in cgetset () from /lib/libc.so.7
>> #2  0x282f64f2 in cgetent () from /lib/libc.so.7
>> #3  0x2824940e in _nc_read_termcap_entry () from /lib/libncursesw.so.7
>> #4  0x2826accf in _nc_read_entry () from /lib/libncursesw.so.7
>> #5  0x28268d47 in _nc_setupterm () from /lib/libncursesw.so.7
>> #6  0x2823d928 in tgetent () from /lib/libncursesw.so.7
>> #7  0x0807bd29 in init_term ()
>> #8  0x0809593b in setstrvalue ()
>> #9  0x08099ba7 in assignsparam ()
>> #10 0x0809ab3e in createparamtable ()
>> #11 0x0807b9df in setupvals ()
>> #12 0x0807d6ce in zsh_main ()
>> #13 0x08052e32 in main ()
>> (gdb)
>>
>> Does gdb seem to be OK?
>
> Yes, the backtrace makes sense.  However, the crash is down inside the
> library code, where zsh calls tgetent().  The shell simply passes down
> the terminal name, i.e. the string "linux", and maybe a buffer.  It's
> going through calls to ncursesw and libc, which is correct.
>
> Do you have the configuration for this version of zsh?  Can you see if
> the option TGETENT_ACCEPTS_NULL is #define'd in config.h?  It should be
> under Linux, but if it wasn't it might be that the 2048-byte buffer was
> too short.  If the option is set, it's hard to see how the shell could
> be causing this.  Indeed, I see in the manual page for tgetent that the
> buffer pointer is ignored, although it wasn't specially about ncursesw.
>
> Can you post the output of "infocmp -C linux" on the system where it's
> crashing?
>
> Thanks.
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

The server side /etc/zshrc:
http://pastebin.com/m65da7ea1

How can I see in zsh of server side if TGETENT_ACCEPTS_NULL is set?

On the server side (where zsh crashes) there is no command 'infocmp'.
The server is running FreeBSD. On the client side, here is the output
of 'infocmp -C linux':
http://pastebin.com/m352212c1

Thanks in advance.

-- 
Murilo Opsfelder Araujo
mopsfelder@gmail.com
{murilo,panda}@bsd.com.br
BSD will never die.
"Tempo difícil esse em que estamos, em que é mais fácil quebrar um
átomo do que um preconceito." - Albert Einstein

Re: zsh seg fault when TERM = linux

[Peter Stephenson]

=?ISO-8859-1?Q?Murilo_Opsfelder_Ara=FAjo?= wrote:
> How can I see in zsh of server side if TGETENT_ACCEPTS_NULL is set?

This would only be in the directory where zsh was originally compiled,
if you don't have that you can't tell.

> On the server side (where zsh crashes) there is no command 'infocmp'.
> The server is running FreeBSD.

So this appears to be something to do with the response of FreeBSD to
being given a TERM setting of "linux"; can you reproduce this by setting
TERM to linux locally on the server?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: zsh seg fault when TERM = linux

[Murilo Opsfelder Araújo]

On Fri, May 1, 2009 at 6:18 AM, Peter Stephenson <pws@csr.com> wrote:
> =?ISO-8859-1?Q?Murilo_Opsfelder_Ara=FAjo?= wrote:
>> How can I see in zsh of server side if TGETENT_ACCEPTS_NULL is set?
>
> This would only be in the directory where zsh was originally compiled,
> if you don't have that you can't tell.

On the server, I unpacked the zsh 4.3.9 and applied all FreeBSD
patches made by ports. After that I greped for TGETENT_ACCPETS_NULL.
See:

server$ cd /usr/ports/shells/zsh
server$ make patch
server$ cd work/zsh-4.3.9
server$ grep -r 'TGETENT_ACCEPTS_NULL' ./
./config.h.in:#undef TGETENT_ACCEPTS_NULL
./Src/init.c:#ifndef TGETENT_ACCEPTS_NULL
./Src/init.c:#ifdef TGETENT_ACCEPTS_NULL
./configure.ac:AH_TEMPLATE([TGETENT_ACCEPTS_NULL],
./configure.ac:  AC_DEFINE(TGETENT_ACCEPTS_NULL)
./configure:#define TGETENT_ACCEPTS_NULL 1

I think these are the options zsh was installed on server. If you need
the options zsh port was compiled, it will take me more time. I have
no root acces on the server.

>> On the server side (where zsh crashes) there is no command 'infocmp'.
>> The server is running FreeBSD.
>
> So this appears to be something to do with the response of FreeBSD to
> being given a TERM setting of "linux"; can you reproduce this by setting
> TERM to linux locally on the server?

I set TERM to 'linux' on the server before calling 'zsh'. All seems
ok. May be a problem with ssh connection.

If you need more, please, let me know.

Thanks.

-- 
Murilo Opsfelder Araujo
mopsfelder@gmail.com
{murilo,panda}@bsd.com.br
BSD will never die.
"Tempo difícil esse em que estamos, em que é mais fácil quebrar um
átomo do que um preconceito." - Albert Einstein

Re: zsh seg fault when TERM = linux

[Peter Stephenson]

On Mon, 4 May 2009 12:58:10 -0300
Murilo Opsfelder Araújo <mopsfelder@gmail.com> wrote:
> ./configure:#define TGETENT_ACCEPTS_NULL 1
> 
> I think these are the options zsh was installed on server. If you need
> the options zsh port was compiled, it will take me more time. I have
> no root acces on the server.

OK, that's what I expected; it means zsh isn't responsible for buffer
allocation (or doesn't think it is, and if it got it wrong the system would
crash immediately, so it must be right).

> >> On the server side (where zsh crashes) there is no command 'infocmp'.
> >> The server is running FreeBSD.
> >
> > So this appears to be something to do with the response of FreeBSD to
> > being given a TERM setting of "linux"; can you reproduce this by setting
> > TERM to linux locally on the server?
> 
> I set TERM to 'linux' on the server before calling 'zsh'. All seems
> ok. May be a problem with ssh connection.

I'm completely stuck now, I'm afraid: something obscure is happening down
in a library on a type of system I don't have access to.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: zsh seg fault when TERM = linux

[Clint Adams]

On Mon, May 04, 2009 at 12:58:10PM -0300, Murilo Opsfelder Araújo wrote:
> ./config.h.in:#undef TGETENT_ACCEPTS_NULL

You need to run configure so that config.h will be generated.  Then you
can check the setting there.

Re: zsh seg fault when TERM = linux

[Peter Stephenson]

On Tue, 5 May 2009 15:40:16 +0000
Clint Adams <clint@zsh.org> wrote:
> On Mon, May 04, 2009 at 12:58:10PM -0300, Murilo Opsfelder Araújo wrote:
> > ./config.h.in:#undef TGETENT_ACCEPTS_NULL
> 
> You need to run configure so that config.h will be generated.  Then you
> can check the setting there.

You're right, I was looking in the wrong file.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070