Re: zsh seg fault when TERM = linux

[Peter Stephenson <pws@csr.com>]

=?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