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 <[EMAIL PROTECTED]> $ perl -e 'while (42) {fork}' "Toda a realidade se resume ao ponto" -- Escola de Pitágoras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
