wayne@teemc.UUCP (Michael R. Wayne) (09/15/90)
Sun 3/140, SunOS 4.0.3, X11R4(patch 14) buit w/ gcc 1.37.
Every time I try to use xterm in tek mode, it dies. gdb on xterm -t
tells me the problem is in the library routine XmuCopyISOLatinLowered called
from TekRealize at line 1292 of xterm/Tekproc.c. Is there a patch to deal
with this one?
/\/\ \/\/
--
Michael R. Wayne --- TMC & Associates --- wayne@teemc.tmc.mi.org
Operator of the only 240 Horsepower UNIX machine in Michigan mouse@LARRY.MCRCIM.MCGILL.EDU (09/17/90)
> Sun 3/140, SunOS 4.0.3, X11R4(patch 14) buit w/ gcc 1.37. > Every time I try to use xterm in tek mode, it dies. gdb on xterm -t > tells me the problem is in the library routine XmuCopyISOLatinLowered > called from TekRealize at line 1292 of xterm/Tekproc.c. Is there a > patch to deal with this one? I thought so, and I thought it was one of the 14. I guess not. The quick kludge fix is to use -fwritable-strings when building xterm. The proper fix is to change whatever's guilty (xterm, I think) so it doesn't try to write into a string literal. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
moraes@cs.toronto.edu (Mark Moraes) (09/18/90)
wayne@teemc.UUCP (Michael R. Wayne) writes: > Every time I try to use xterm in tek mode, it dies. gdb on xterm -t >tells me the problem is in the library routine XmuCopyISOLatinLowered called >from TekRealize at line 1292 of xterm/Tekproc.c. Is there a patch to deal >with this one? Here's a copy of a bug report we filed with xbugs in January -- strictly unblessed and unsupported, of course! From: jonah@dgp.toronto.edu To: xbugs@expo.lcs.mit.edu Subject: xterm core dumps when openning tek window X Window System Bug Report xbugs@expo.lcs.mit.edu VERSION: R4 CLIENT MACHINE and OPERATING SYSTEM: Sun 3/280 running SunOS 3.5 DISPLAY TYPE: Sun /dev/fb (mono) WINDOW MANAGER: twm AREA: xterm/Xaw/Xmu/Xt SYNOPSIS: When I try to open the tek window in xterm, xterm just quits with a "memory fault" DESCRIPTION: In Texproc.c, XmuCopyISOLatin1Lowered is called with the same string for the source and destination -- but the string comes from the toolkit and might be a static (non-writable) string. (gdb) bt #0 0x1734c in XmuCopyISOLatin1Lowered () #1 0x1013a in TekRun () #2 0x22fd8 in _XtIsSubclassOf () #3 0x23074 in _XtIsSubclassOf () #4 0x23108 in XtRealizeWidget () #5 0xfa1e in TekRun () #6 0x3824 in main () REPEAT BY: Compile xterm, Xaw, Xt, and Xmu with gcc (1.35) but without -fwritable-strings. Start-up an xterm and try to open a tek window from the menu. Run gdb and look at the backtrace. Note: Before you get to this bug, you may have to compensate for the fact that many libraries have a broken sscanf() which may also try to modify a ``const'' (ANSI C) string argument. We'd send you the fix to this one too, but it's a patch to non-redistributable code. SAMPLE FIX: *** /tmp/,RCSt1a00417 Thu Jan 18 21:48:06 1990 --- mit/clients/xterm/Tekproc.c Thu Jan 18 21:18:14 1990 *************** *** 1288,1303 **** screen->cur.fontsize = TEK_FONT_LARGE; if (tw->tek.initial_font) { char *s = tw->tek.initial_font; ! XmuCopyISOLatin1Lowered (s, s); ! if (strcmp (s, "large") == 0) screen->cur.fontsize = TEK_FONT_LARGE; ! else if (strcmp (s, "2") == 0 || strcmp (s, "two") == 0) screen->cur.fontsize = TEK_FONT_2; ! else if (strcmp (s, "3") == 0 || strcmp (s, "three") == 0) screen->cur.fontsize = TEK_FONT_3; ! else if (strcmp (s, "small") == 0) screen->cur.fontsize = TEK_FONT_SMALL; } gcv.graphics_exposures = TRUE; /* default */ --- 1288,1309 ---- screen->cur.fontsize = TEK_FONT_LARGE; if (tw->tek.initial_font) { char *s = tw->tek.initial_font; + char *slow = (char*) malloc(strlen(s)+1); ! if (slow == (char*)NULL) { ! fprintf(stderr, "%s: malloc failed\n", xterm_name); ! goto mallocfailed; ! } ! XmuCopyISOLatin1Lowered (slow, s); ! if (strcmp (slow, "large") == 0) screen->cur.fontsize = TEK_FONT_LARGE; ! else if (strcmp (slow, "2") == 0 || strcmp (slow, "two") == 0) screen->cur.fontsize = TEK_FONT_2; ! else if (strcmp (slow, "3") == 0 || strcmp (slow, "three") == 0) screen->cur.fontsize = TEK_FONT_3; ! else if (strcmp (slow, "small") == 0) screen->cur.fontsize = TEK_FONT_SMALL; + free(slow); } gcv.graphics_exposures = TRUE; /* default */
khera@thneed.cs.duke.edu (Vick Khera) (09/18/90)
In article <90Sep17.174858edt.382@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: wayne@teemc.UUCP (Michael R. Wayne) writes: > Every time I try to use xterm in tek mode, it dies. gdb on xterm -t >tells me the problem is in the library routine XmuCopyISOLatinLowered called >from TekRealize at line 1292 of xterm/Tekproc.c. Is there a patch to deal >with this one? Here's a copy of a bug report we filed with xbugs in January -- strictly unblessed and unsupported, of course! [report deleted] here's my version, much simpler... v. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vick Khera Gradual Student Department of Computer Science ARPA: khera@cs.duke.edu Duke University UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528 *** /tmp/,RCSt1018705 Mon Sep 17 10:51:16 1990 --- Tekproc.c Fri Jul 13 10:19:17 1990 *************** *** 218,223 static Dimension defOne = 1; static XtResource resources[] = { {XtNwidth, XtCWidth, XtRDimension, sizeof(Dimension), XtOffset(Widget, core.width), XtRDimension, (caddr_t)&defOne}, --- 218,227 ----- static Dimension defOne = 1; + /* prevent gcc from making initial font name read-only, causing core dump */ + /* when XmuCopyISOLatin1Lowered() is called to copy it onto itself */ + static char initialFontStr[] = "large"; + static XtResource resources[] = { {XtNwidth, XtCWidth, XtRDimension, sizeof(Dimension), XtOffset(Widget, core.width), XtRDimension, (caddr_t)&defOne}, *************** *** 237,243 XtRString, "6x10"}, {"initialFont", "InitialFont", XtRString, sizeof(char *), XtOffset(TekWidget, tek.initial_font), ! XtRString, "large"}, }; static void TekInitialize(), TekRealize(), TekConfigure(); --- 241,247 ----- XtRString, "6x10"}, {"initialFont", "InitialFont", XtRString, sizeof(char *), XtOffset(TekWidget, tek.initial_font), ! XtRString, initialFontStr}, }; static void TekInitialize(), TekRealize(), TekConfigure(); -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vick Khera Gradual Student Department of Computer Science ARPA: khera@cs.duke.edu Duke University UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528