Summary: Wingz:Help!

> Has anyone else experienced segmentation faults when trying to print > a worksheet? Scenario: user starts Wingz, opens a new sheet, makes > a single entry, selects "Print", accepts all defaults in the "Margins" > dialog and press "OK", selects a printer from the next dialog, > presses "OK", a segmentation fault occurs, and Wingz crashes. > (Most users lose all their work at this point). > > Traces always end with lines similar to the following: > > stat ("/dev/ttyp7", 0xf7ffde28) = 0 > close (8) = 0 > open ("/etc/ttytab", 0, 0666) = 8 > ioctl (8, 0x40125401, 0xf7ffdcd4) = -1 ENOTTY (Inappropriate ioctl for device) > fstat (8, 0xf7ffdd48) = 0 > read (8, "#\\n# @(#)ttytab 1.6 89/12/18 SMI\\n".., 8192) = 8192 > lseek (8, -6760, 1) = 1432 > close (8) = 0 > open ("/etc/utmp", 0, 036736413320) = 8 > lseek (8, 972, 0) = 972 > read (8, "".., 36) = 36 > close (8) = 0 > open ("/etc/passwd", 0, 0666) = 8 > ioctl (8, 0x40125401, 0xf7ffd974) = -1 ENOTTY (Inappropriate ioctl for device) > fstat (8, 0xf7ffd9e8) = 0 > read (8, "root:84No2U8ypHHdw:0:1:Operator:".., 8192) = 335 > stat ("/dev/ttyp7", 0xf7ffde28) = 0 > close (8) = 0 > open ("/etc/ttytab", 0, 0666) = 8 > ioctl (8, 0x40125401, 0xf7ffdcd4) = -1 ENOTTY (Inappropriate ioctl for device) > fstat (8, 0xf7ffdd48) = 0 > read (8, "#\\n# @(#)ttytab 1.6 89/12/18 SMI\\n".., 8192) = 8192 > lseek (8, -6760, 1) = 1432 > close (8) = 0 > open ("/etc/utmp", 0, 036736413320) = 8 > lseek (8, 972, 0) = 972 > read (8, "".., 36) = 36 > close (8) = 0 > open ("/etc/passwd", 0, 0666) = 8 > ioctl (8, 0x40125401, 0xf7ffd974) = -1 ENOTTY (Inappropriate ioctl for device) > fstat (8, 0xf7ffd9e8) = 0 > read (8, "root:xxxxxxxxxxxxx:0:1:Operator:".., 8192) = 335 > > > (Why is it looking there, anyway?). > > SunOS 4.1.1, X11R4, more often than not using ncd X Terminals. I've looked > at a lot of things... Wingz evidently uses a getlogin() call. getlogin() returns a null string if the current process isn't assosciated with a controlling terminal, or if there isn't a valid entry in /etc/utmp. Wingz doesn't appear to handle a null return cleanly. I'm pretty sure now that Wingz is consistenly breaking when executed from our window manager menus when the window manager was started by xdm or when Wingz was started from a Unix prompt within an emacs buffer. Both scenarios fail to provide either the required controlling terminal or utmp entry. One suggestion was to start Wingz in an xterm from a window manager. (Don't use the "-ut" option inhibiting generation of a utmp entry). I also understand that it's possible to have xdm generate a utmp entry, though I don't know whether this would help. (Obviously, executing Wingz from a Unix prompt within an xterm also works.) I suppose having Wingz not use getlogin() might also work ;-) Thanks to stuart@genethon.genethon.fr and kevink@cisco.com for their prompt responses. - Tim Tim Medley Board of Governors of the Federal Reserve System tlm@frb.gov Washington, D.C. 20551 uunet!fed!tlm (202) 452-3148 --------------------------------------------------------------------------- Between the wish and the thing, the world lies waiting. (Cormac McCarthy)