hook@geog.ubc.ca (Chris Hook) (02/06/90)
I'm wondering if anyone else has had the following problem: If I try to get Tektronics terminal emulation on an xterm (either by doing an xterm -t, or selecting Tektronics mode from the xterm menu), I get an immediate segmentation fault and a core dump. This is done on a sun 3/60, with display device /dev/cgfour0, and running SunOS 4.0, and, by the way, using X11R4 (with the patches1 installed). I built X11R4 (and so, xterm as well) using gcc1.36, with the fixes included for gcc1.36 building X11R4. Everything else seems to work fine with regards to xterm. I have also built the same set of patched X11R4 files on our SPARCstation 1's using just the standard cc compiler. Here, of course, I use display device /dev/cgthree0, and run SunOS4.0.3c. On this platform, I have NO problems with xterm and Tektronics mode. Anty help would be appreciated. Chris Hook. hook@geog.ubc.ca
morreale@bierstadt.ucar.edu (Peter Morreale) (02/06/90)
In article <76*hook@geog.ubc.ca>, hook@geog.ubc.ca (Chris Hook) writes: > > I'm wondering if anyone else has had the following problem: > > If I try to get Tektronics terminal emulation on an xterm (either > by doing an xterm -t, or selecting Tektronics mode from the xterm > menu), I get an immediate segmentation fault and a core dump. > > This is done on a sun 3/60, with display device /dev/cgfour0, and > running SunOS 4.0, and, by the way, using X11R4 (with the patches1 > installed). I built X11R4 (and so, xterm as well) using gcc1.36, > with the fixes included for gcc1.36 building X11R4. Everything else > seems to work fine with regards to xterm. > > I have also built the same set of patched X11R4 files on our SPARCstation 1's > using just the standard cc compiler. Here, of course, I use display device > /dev/cgthree0, and run SunOS4.0.3c. On this platform, I have NO problems > with xterm and Tektronics mode. > I have a similar problem using the Tek window with tn3270 in the loop. What I mean is as follows: I use a local xterm to connect to an IBM mainframe running VM/CMS with tn3270. I open up the Tek window and use a locally developed translator (on CMS) to attempt to view a CGM. WHen I tell the translator to view the frame, I get garbage to the Tek window with "TYPEAHEAD BUFFER FULL" messages written all across the Tek window. If I use the "same" translator on my workstation, (the UNIX version) the Tek window works as advertised. (Note that tn3270 is not in the loop in this case.) Under R3, xterm worked in both cases. ( ie. +/- tn3270) Before I installed the first set of fixes, xterm dumped core. With the fixes installed, I get the "TYPEAHEAD" messages described above, and no core dump. Note that the only thing which has changed in this environment has been the upgrade to R4. The translator and tn3270 versions are the same as I used under R3. Particulars: Sun 3/60C SunOS 4.0.3 X11R4 with fixes-1 built with "cc" (default) any guesses? -PWM ------------------------------------------------------------------ Peter W. Morreale email: morreale@ncar.ucar.edu Nat'l Center for Atmos Research voice: (303) 497-1293 Scientific Computing Division Consulting Office ------------------------------------------------------------------
dl2n+@ANDREW.CMU.EDU (Daniel Edward Lovinger) (02/06/90)
> This is done on a sun 3/60, with display device /dev/cgfour0, and > running SunOS 4.0, and, by the way, using X11R4 (with the patches1 > installed). I built X11R4 (and so, xterm as well) using gcc1.36, > with the fixes included for gcc1.36 building X11R4. Everything else > seems to work fine with regards to xterm. Gcc 1.36 is your problem. I built the release (no fix-1) under gcc 1.36 and got the exact behavior you describe. A rebuild with Sun 0S 4.0.3 cc -O2 has yet to give me any problems, however. Suggestion - wait for gcc 1.37, or back out your version of gcc to 1.35. Something is tripping one of the few remaining bugs in there somewhere. Dan Lovinger CMU Architecture
dl2n+@ANDREW.CMU.EDU (Daniel Edward Lovinger) (02/06/90)
With the assistance of a line eater, I write (in a previous message) : >> This is done on a sun 3/60, with display device /dev/cgfour0, and >> running SunOS 4.0, and, by the way, using X11R4 (with the patches1 >> installed). I built X11R4 (and so, xterm as well) using gcc1.36, >> with the fixes included for gcc1.36 building X11R4. Everything else >> seems to work fine with regards to xterm. > > Gcc 1.36 is your problem. I built the release (no fix-1) under >gcc 1.36 and got the exact behavior you describe. A rebuild with Sun >0S 4.0.3 cc -O2 has yet to give me any problems, however. > > Suggestion - wait for gcc 1.37, or back out your version of >gcc to 1.35. Something is tripping one of the few remaining bugs in >there somewhere. I am refering to an xterm coredump when the TEK window is requested. Sorry for the confusion ... Dan Lovinger CMU Architecture
casey@gauss.llnl.gov (Casey Leedom) (02/06/90)
| From: dl2n+@ANDREW.CMU.EDU (Daniel Edward Lovinger) | | Gcc 1.36 is your problem. Suggestion - wait for gcc 1.37, or back out | your version of gcc to 1.35. Something is tripping one of the few | remaining bugs in there somewhere. GCC is not the problem. Unless you want to call it putting strings in read-only storage by default a bug. The problem is that xterm is trying to overwrite a string in read-only storage and getting the segmentation violation then. You can wait for new GCC releases until your face turns blue, but it won't help you unless GCC decides to put strings into read/write storage by default. Someone else already posted their fix for this, here's mine: *** mit/clients/xterm/Tekproc.c-dist Fri Dec 22 08:40:41 1989 --- mit/clients/xterm/Tekproc.c Mon Feb 5 23:48:24 1990 *************** *** 1287,1295 **** 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) --- 1287,1298 ---- screen->cur.fontsize = TEK_FONT_LARGE; if (tw->tek.initial_font) { ! char *s; ! s = malloc(strlen(tw->tek.initial_font)+1); ! if (s == NULL) ! Panic("TekRealize: malloc error (%d)\n", errno); ! XmuCopyISOLatin1Lowered (s, tw->tek.initial_font); if (strcmp (s, "large") == 0) screen->cur.fontsize = TEK_FONT_LARGE; else if (strcmp (s, "2") == 0 || strcmp (s, "two") == 0) *************** *** 1298,1303 **** --- 1301,1307 ---- screen->cur.fontsize = TEK_FONT_3; else if (strcmp (s, "small") == 0) screen->cur.fontsize = TEK_FONT_SMALL; + free(s); } gcv.graphics_exposures = TRUE; /* default */ Alternatively, you can simply compile Tekproc.c with -fwriteable-strings. Casey
jensen@bessel.eedsp.gatech.edu (P. Allen Jensen) (02/09/90)
I cannot get xterm to go into tek mode using the mouse selection
either (X.V11R4 - Sun-3/60, SunOS 4.0.1, gcc 1.36.92)
Window just goes away - both on cgfour and bwtwo screens
Any help would be appretiated.
P. Allen Jensen
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332
USENET: ...!{allegra,hplabs,ulysses}!gatech!eedsp!jensen
INTERNET: jensen@eedsp.gatech.edu