Bug#459041: xterm: version 230-1 segfaults somewhere when involving cut and paste

[Caetano Jimenez Carezzato <caetano@vision.ime.usp.br>]

  I believe that when xterm is not in wide-character mode no memory is
  allocated for the WIDEC pointer, meaning that SCRN_BUF_WIDEC(screen, row)
  is going to translate to screen->visbuf[MAX_PTRS * (row) + OFF_WIDEC]
  which in this case is a lost pointer.

  MAX_PTRS can have differente sizes:

ptyx.h
 945         /* the number of pointers per row in 'ScrnBuf' */
 946 #if OPT_WIDE_CHARS
 947 #define MAX_PTRS term->num_ptrs
 948 #else
 949 #define MAX_PTRS (OFF_FINAL)
 950 #endif

 When OPT_WIDE_CHARS is true, several parts of the code changes
 term->num_ptrs value if wide-character mode is active or not.

  As MAX_PTRS is used to allocate the pointer array,
  screen->visbuf[MAX_PTRS * (row) + OFF_WIDEC] is a lost pointer when
  OPT_WIDE_CHARS is false or when (OPT_WIDE_CHARS is true and
  wide-character mode is off)

  Thanks

Thomas Dickey writes:
> On Fri, Jan 04, 2008 at 04:10:17PM +0100, Caetano Jimenez Carezzato wrote:
> >   If I downgrade xterm to 229-1 the problem doesn't happen.
> >   Here the bug under gdb (AMD64)
> > 
> > [vrz002:~]$ gdb /tmp/deb/xterm-230/debian/xterm/usr/bin/xterm
> > GNU gdb 6.7.1-debian
> > Copyright (C) 2007 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu"...
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > (gdb) r
> > Starting program: /tmp/deb/xterm-230/debian/xterm/usr/bin/xterm 
> > [Thread debugging using libthread_db enabled]
> > [New Thread 0x2ba542e20860 (LWP 15406)]
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x2ba542e20860 (LWP 15406)]
> > 0x000000000044f09e in getXtermCell (screen=0x6b20d8, row=0, col=29) at ../util.c:3500
> > 3500        return PACK_PAIR(SCRN_BUF_CHARS(screen, row),
> 
> In context:
> 
> unsigned
> getXtermCell(TScreen * screen, int row, int col)
> {   
>     return PACK_PAIR(SCRN_BUF_CHARS(screen, row),
>                      SCRN_BUF_WIDEC(screen, row),
>                      col);
> }
> 
> where
> 
> #define PACK_PAIR(lo,hi,n)      (lo[n] | (hi ? (hi[n] << 8) : 0))
> 
> The one issue that I did foresee here would be a null pointer from 
> SCRN_BUF_WIDEC(screen, row).  In #229, that function looks like
> 
> unsigned
> getXtermCell(TScreen * screen, int row, int col)
> {
>     unsigned ch = SCRN_BUF_CHARS(screen, row)[col]; 
>     if_OPT_WIDE_CHARS(screen, { 
>        ch |= (SCRN_BUF_WIDEC(screen, row)[col] << 8); 
>     }); 
>     return ch; 
> }
> 
> ...which should have the same effect.
> 
> SCRN_BUF_WIDEC(screen, row) should be null whenever xterm's not in
> wide-character mode.   So I'm not seeing a functional difference
> at this level.
> 
> valgrind is useful for spotting things that gdb and a core dump won't
> show - but on my Intel 32-bit box I'm not seeing anything.
> 



-- 
  Caetano Jimenez Carezzato   <caetano@vision.ime.usp.br>

            $ perl -e 'while (42) {fork}'

"Toda a realidade se resume ao ponto" -- Escola de Pitágoras