xterm on x86_64 intermittently segfaults when ~/XTerm contains "*scrollBar: true" and "*saveLines: 100000"

Adding an attachment.

Place this file in your $HOME to reproduce the problem:

$ xterm &
[2] 7210
$ xterm &
[3] 7227
$ xterm &
[4] 7244
$ xterm &
[5] 7245
[4] Segmentation fault xterm
$ xterm &
[6] 7262
$ xterm &
[7] 7279
[1] Done xterm
[2] Done xterm
[3] Done xterm
[5] Done xterm
[6] Done xterm
$ xterm &
[8] 7280
[7] Segmentation fault xterm

The problem doesn't occur (using the same configuration file) using
Ubuntu Gutsy 7.10 on x86 machines, it seems to occur only on x86_64.

The problem didn't occur on Ubuntu Feisty Fawn on x86_64 (I had been previously using
the same configuration file on the iMac machine when it was running Feisty Fawn, although
I no longer have that environment available any more as the machine is running Gutsy now).

On Fri, Dec 14, 2007 at 16:59:28 -0000, PeterKnaggs wrote:

> Adding an attachment.
>
> Place this file in your $HOME to reproduce the problem:
>
> $ xterm &
> [2] 7210
> $ xterm &
> [3] 7227
> $ xterm &
> [4] 7244
> $ xterm &
> [5] 7245
> [4] Segmentation fault xterm

Please rebuild xterm with debugging symbols and run it under gdb to get
a backtrace.

Cheers,
Julien

sudo apt-get install libxaw-headers libxaw7-dev libncurses5-dev

$ apt-get source xterm
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 904kB of source archives.
Get:1 http://us.archive.ubuntu.com gutsy/main xterm 229-1 (dsc) [805B]
Get:2 http://us.archive.ubuntu.com gutsy/main xterm 229-1 (tar) [842kB]
Get:3 http://us.archive.ubuntu.com gutsy/main xterm 229-1 (diff) [62.1kB]
Fetched 904kB in 12s (74.6kB/s)
gpg: Signature made Mon 13 Aug 2007 07:20:07 AM PDT using DSA key ID AC5F700C
gpg: Can't check signature: public key not found
dpkg-source: extracting xterm in xterm-229
dpkg-source: unpacking xterm_229.orig.tar.gz
dpkg-source: applying ./xterm_229-1.diff.gz

cd ~/xterm-229

./configure
make xterm

...

xterm-229/./main.c:3312: undefined reference to `tgetstr'
xtermcap.o: In function `get_termcap':
xterm-229/./xtermcap.c:327: undefined reference to `tgetent'
collect2: ld returned 1 exit status
make: *** [xterm] Error 1

Not sure if these are the right steps to build xterm with debug symbols.

Ah, sorry. I added "-lncurses" to the end of the link line, and now xterm links OK using:

gcc -g -O2 -o xterm button.o cachedGCs.o charproc.o charsets.o \
cursor.o data.o doublechr.o fontutils.o input.o main.o menu.o misc.o \
print.o ptydata.o screen.o scrollbar.o tabs.o util.o xstrings.o xtermcap.o \
VTPrsTbl.o TekPrsTbl.o Tekproc.o \
-lXft -lfontconfig -lXaw -lXmu -lXext -lXt -lSM -lICE -lX11 -lncurses

But the problem doesn't reproduce with the xterm built this way, only with the original xterm from gutsy.
But at least it's nice to be able to reliably launch xterm with the scroll bar again, using this debug build.

The bug doesn't appear to be in xterm, because disabling compiz-fusion
by adding the following line:

export WINDOW_MANAGER=metacity

to $HOME/.gnomerc

causes the bug to no longer occur.

The stack trace from "gdb /usr/bin/xterm" (i.e. without debug symbols) and doing "run" over and over again until the problem reproduces is:

(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47700464508768 (LWP 8075)]
0x0000000000430b42 in ?? ()
(gdb) where
#0 0x0000000000430b42 in ?? ()
#1 0x0000000000425544 in ?? ()
#2 0x000000000042cfd7 in ?? ()
#3 0x000000000040ddaa in ?? ()
#4 0x00002b621f1bd8a6 in ?? () from /usr/lib/libXt.so.6
#5 0x00002b621f1bd9ee in ?? () from /usr/lib/libXt.so.6
#6 0x00002b621f1bdc80 in XtRealizeWidget () from /usr/lib/libXt.so.6
#7 0x000000000040fe5b in ?? ()
#8 0x000000000041e236 in ?? ()
#9 0x0000000000420257 in ?? ()
#10 0x00002b621fda7b44 in __libc_start_main () from /lib/libc.so.6
#11 0x00000000004075b9 in ?? ()
#12 0x00007fff8c614c48 in ?? ()
#13 0x0000000000000000 in ?? ()

So disabling compiz-fusion appears to be another workaround.

On Tue, Dec 18, 2007 at 18:01:15 -0000, PeterKnaggs wrote:

> The stack trace from "gdb /usr/bin/xterm" (i.e. without debug symbols)
> and doing "run" over and over again until the problem reproduces is:
>
> (no debugging symbols found)
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 47700464508768 (LWP 8075)]
> 0x0000000000430b42 in ?? ()
> (gdb) where
> #0 0x0000000000430b42 in ?? ()
> #1 0x0000000000425544 in ?? ()
> #2 0x000000000042cfd7 in ?? ()
> #3 0x000000000040ddaa in ?? ()
> #4 0x00002b621f1bd8a6 in ?? () from /usr/lib/libXt.so.6
> #5 0x00002b621f1bd9ee in ?? () from /usr/lib/libXt.so.6

Can you install the libxt6-dbg package and try again?

Strangely, when running "valgrind /usr/bin/xterm" it gives:
  valgrind: /usr/bin/xterm: Permission denied
Whereas when running "valdrind ~/xterm-229/xterm" (i.e. on the one I built from the sources) gives:

==8270== Memcheck, a memory error detector.
==8270== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==8270== Using LibVEX rev 1732, a library for dynamic binary translation.
==8270== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==8270== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation framework
.
==8270== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==8270== For more details, rerun with: -v
==8270==
==8270== Syscall param write(buf) points to uninitialised byte(s)
==8270== at 0x65C2D50: write (in /lib/libc-2.6.1.so)
==8270== by 0x5D7E02E: (within /usr/lib/libICE.so.6.3.0)
==8270== by 0x5D81957: _IceWrite (in /usr/lib/libICE.so.6.3.0)
==8270== by 0x5D81A33: IceFlush (in /usr/lib/libICE.so.6.3.0)
==8270== by 0x5943DA6: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5924528: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5924F89: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5925349: _XtAppCreateShell (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x59255A8: XtAppCreateShell (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x5930971: XtOpenApplication (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x41C763: main (main.c:1982)
==8270== Address 0x40A8B7C is 12 bytes inside a block of size 1,024 alloc'd
==8270== at 0x4C20F3F: calloc (vg_replace_malloc.c:279)
==8270== by 0x5D7A40B: IceOpenConnection (in /usr/lib/libICE.so.6.3.0)
==8270== by 0x5B6EBC3: SmcOpenConnection (in /usr/lib/libSM.so.6.0.0)
==8270== by 0x5943B1B: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x594403A: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5924528: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5924F89: (within /usr/lib/libXt.so.6.0.0)
==8270== by 0x5925349: _XtAppCreateShell (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x59255A8: XtAppCreateShell (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x5930971: XtOpenApplication (in /usr/lib/libXt.so.6.0.0)
==8270== by 0x41C763: main (main.c:1982)
==8270==
==8270== Invalid read of size 8
==8270== at 0x4015B3E: (within /lib/ld-2.6.1.so)
==8270== by 0x400A8F7: (within /lib/ld-2.6.1.so)
==8270== by 0x4006174: (within /lib/ld-2.6.1.so)
==8270== by 0x40085F7: (within /lib/ld-2.6.1.so)
==8270== by 0x4011C98: (within /lib/ld-2.6.1.so)
==8270== by 0x400DA05: (within /lib/ld-2.6.1.so)
==8270== by 0x401155A: (within /lib/ld-2.6.1.so)
==8270== by 0x7732F8A: (within /lib/libdl-2.6.1.so)
==8270== by 0x400DA05: (within /lib/ld-2.6.1.so)
==8270== by 0x77334EC: (within /lib/libdl-2.6.1.so)
==8270== by 0x7732EF0: dlopen (in /lib/libdl-2.6.1.so)
==8270== by 0x5FB5B9C: (within /usr/lib/libX11.so.6.2.0)
==8270== Address 0x40C3D38 is 24 bytes inside a block of size 25 alloc'd
==8270== at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==8270== by 0x4008AF5: (within /lib/ld-2.6.1.so)
==8270== by 0x4011C98: (within /lib/ld-2.6.1.so)
==8270== by 0x400DA05: (within /lib/ld-2.6.1.so)
==8270== by 0x40...

After installing libxt6-dbg (apt-get install libxt6-dbg) and running under gdb, it gives:

$ gdb /usr/bin/xterm
GNU gdb 6.6-debian
Copyright (C) 2006 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 "x86_64-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/xterm
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46956537999200 (LWP 8437)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46956537999200 (LWP 8437)]
0x0000000000430b42 in ?? ()
(gdb) where
#0 0x0000000000430b42 in ?? ()
#1 0x0000000000425544 in ?? ()
#2 0x000000000042cfd7 in ?? ()
#3 0x000000000040ddaa in ?? ()
#4 0x00002ab4e9a228a6 in RealizeWidget (widget=0x691f30)
    at ../../src/Intrinsic.c:306
#5 0x00002ab4e9a229ee in RealizeWidget (widget=0x6825e0)
    at ../../src/Intrinsic.c:355
#6 0x00002ab4e9a22c80 in XtRealizeWidget (widget=<value optimized out>)
    at ../../src/Intrinsic.c:385
#7 0x000000000040fe5b in ?? ()
#8 0x000000000041e236 in ?? ()
#9 0x0000000000420257 in ?? ()
#10 0x00002ab4ea60cb44 in __libc_start_main () from /lib/libc.so.6
#11 0x00000000004075b9 in ?? ()
#12 0x00007fffc1db23d8 in ?? ()
#13 0x0000000000000000 in ?? ()

(this is with compiz-fusion enabled. When running with metacity as the window manager, the bug doesn't happen).

Tested that this bug also reproduces in Gutsy on x86 (not only on x86_64) when running compiz-fusion with the nVidia drivers (running Gutsy on a Dell box http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoDellDimensionXPS
 with an nVidia 5200 card: http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoNvidia5200 )

Tested that this bug also reproduces in Gutsy x86 when running compiz-fusion with the
open-source i810 driver, on a HP/Compaq dc7600 desktop.

As on x86_64, rebuilding xterm on x86 from source with debug symbols is a workaround (problem doesn't occur):
  sudo apt-get install libxaw-headers libxaw7-dev libncurses5-dev
  apt-get source xterm
  cd ~/xterm-229
  ./configure
  make xterm
Running ./xterm, it works fine.

The workaround of using the metacity window manager also works fine on x86 too (adding the line "export WINDOW_MANAGER=metacity" to the file $HOME/.gnomerc).

Quick question about Ubuntu Launchpad: Is there a way to update this bug, so that it
is associated mainly with the compiz-fusion package instead of with the xterm package?

Tested that this bug also reproduces in Gutsy x86 when running compiz-fusion
with the open-source "ati" driver

Section "Device"
        Identifier "ATI Technologies Inc R423 UK [Radeon X800SE (PCIE)]"
        Driver "ati"
        BusID "PCI:1:0:0"
EndSection

This is on a Dell XPS desktop (http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoDellDimensionXPS)
with an ATI X800 card (http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoATIRadeonX800).

I'll try with the alpha of Hardy soon.

Tested on the XPS machine with the free "ati" driver
  http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoDellDimensionXPS
  http://www.penlug.org/twiki/bin/view/Main/LinuxHardwareInfoATIRadeonX800
running the Live CD of hardy-desktop-i386.iso (the January 2008 one with
18b9db3935b2910e4afdb9816cfd2e0b MD5SUM), and
the problem reproduces in the same way.

 affects ubuntu/compiz
 status invalid
 affects ubuntu/libxt
 status invalid
 affects ubuntu/xterm
 status invalid

Thank you for taking the time to report this bug and helping to make
Ubuntu better. However, your crash report is either missing or
challenging to deal with as a ".crash" file. Please follow these
instuctions to have apport report a new bug about your crash that can be
dealt with by the automatic retracer.

If you are using Ubuntu with the Gnome desktop environment - launch
nautilus and navigate to your /var/crash directory and double click on
the crash report you wish to submit.
If you are using Kubuntu or Xubuntu you can file the crash using
"/usr/share/apport/apport-qt
--crash-file=/var/crash/_my_crash_report.crash" in a terminal - where
_my_crash_report.crash is the crash you would like to report.

I'm closing this bug report since the process outlined above will
automatically open a new bug report which can then dealt with more
efficiently. Thanks in advance for your cooperation and understanding.