Description of problem: I tried that on two different machines - one i386 and another x86_64. On both opening xterm while display is forwarded via ssh ends up with "Segmentation fault". No sure how a displaying machine is essential but in both cases this is the same client running CentOS 4.6. With xterm-debuginfo and libX11-debuginfo (version 1.1.3-4.fc8) loaded I see the following backtrace from i386 machine Core was generated by `xterm'. Program terminated with signal 11, Segmentation fault. #0 0x03364328 in XFindOnExtensionList (structure=0x9c3e898, number=1040697125) at InitExt.c:123 123 while (ext && (ext->number != number)) (gdb) where #0 0x03364328 in XFindOnExtensionList (structure=0x9c3e898, number=1040697125) at InitExt.c:123 #1 0x0335b7e2 in _XF86BigfontFreeFontMetrics (fs=0x9c3e898) at Font.c:662 #2 0x0335b8cd in XFreeFont (dpy=0x9c1c358, fs=0x9c3e898) at Font.c:169 #3 0x080601c8 in xtermCloseFont (xw=0x9c376c0, fnt=0x9c38a64) at ./fontutils.c:709 #4 0x08060214 in xtermCloseFonts (xw=0x9c376c0, fnts=0x9c38a34) at ./fontutils.c:724 #5 0x08061051 in xtermLoadFont (xw=0x9c376c0, fonts=0xbff1e29c, doresize=1, fontnum=0) at ./fontutils.c:966 #6 0x08061ace in SetVTFont (xw=0x9c376c0, which=0, doresize=1, fonts=0x0) at ./fontutils.c:2563 #7 0x0805cfaa in VTRealize (w=0x9c376c0, valuemask=0xbff1e3b8, values=0xbff1e36c) at ./charproc.c:6080 #8 0x00b4c471 in ?? () from /usr/lib/libXt.so.6 #9 0x00b4c5fa in ?? () from /usr/lib/libXt.so.6 #10 0x00b4c8ae in XtRealizeWidget () from /usr/lib/libXt.so.6 #11 0x08054c39 in VTInit () at ./charproc.c:5007 #12 0x08065191 in spawnXTerm (xw=0x9c376c0) at ./main.c:3215 #13 0x080671d3 in main (argc=Cannot access memory at address 0x73694d2d ) at ./main.c:2262 (gdb) list 118 int number) 119 { 120 XExtData *ext; 121 122 ext = *structure; 123 while (ext && (ext->number != number)) 124 ext = ext->next; 125 return ext; 126 } 127 (gdb) p ext $1 = (XExtData *) 0x73694d2d (gdb) p *ext Cannot access memory at address 0x73694d2d (gdb) f 3 #3 0x080601c8 in xtermCloseFont (xw=0x9c376c0, fnt=0x9c38a64) at ./fontutils.c:709 709 XFreeFont(screen->display, fnt->fs); (gdb) list 704 { 705 if (fnt != 0 && fnt->fs != 0) { 706 TScreen *screen = TScreenOf(xw); 707 708 clrCgsFonts(xw, WhichVWin(screen), fnt); 709 XFreeFont(screen->display, fnt->fs); 710 } 711 return 0; 712 } 713 (gdb) p *fnt $2 = {chrset = 0, flags = 0, fs = 0x9c3e898, fn = 0x9c3d070 "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-120-ISO10646-1"} (gdb) p fnt $3 = (XTermFonts *) 0x9c38a64 (gdb) p *fnt->fs $4 = {ext_data = 0x73694d2d, fid = 1766206819, direction = 761554296, min_char_or_byte2 = 1684828002, max_char_or_byte2 = 707613229, min_byte1 = 825043501, max_byte1 = 842083635, all_chars_exist = 892808496, default_char = 758462253, n_properties = 808856899, properties = 0x4f53492d, min_bounds = {lbearing = 12337, rbearing = 13366, width = 11574, ascent = 49, descent = -1, attributes = 65535}, max_bounds = {lbearing = 64, rbearing = 0, width = 89, ascent = 0, descent = 0, attributes = 0}, per_char = 0x1000014, ascent = 0, descent = 0} An access to this 'ext_data' address eventually is causing segfault. Version-Release number of selected component (if applicable): xterm-232-1.fc8 libX11-1.1.3-4.fc8 How reproducible: always Additional info: Opening the same manner few other applications, among those gnome-terminal, xpdf, texdoctk and others does not show any ill-effects. texdoctk got on that list as for quite some time opening that, especially from a remote, was causing segfaults. Compare with bug 210718 which was closed only quite recently. I wonder if there are any common points with bug 375131 ? A core file is below 2M. Should I attach it to this report?
This looks like a duplicate of bug #435439, can you please try xterm-234-1.fc8 from updates testing?
You may be right about a duplicate. With xterm-234-1.fc8 and it the same conditions an xterm window did show up. OTOH before that I tried with another client, running Fedora 7 this time, and this worked too still with xterm-232-1.fc8. Depends on which fonts are available?
Yes, the corresponding entry from #233 changelog is - fix a case where an incorrect font was freed during initialization from patch #232 changes (patch by Andrea Odetti).
*** This bug has been marked as a duplicate of 435439 ***