[SunHELP] vi crashes
Nicholas Dronen
ndronen at frii.com
Fri Jan 11 09:15:54 CST 2002
On Fri, Jan 11, 2002 at 07:59:15AM -0600, Alan Rubin wrote:
> can anyone decipher this for me? maybe there is a permission error?
Sure, but truss won't show you where exactly in the process
it's getting the signal. If you have Solaris 8, you can use
the -u flag, which shows the symbols and arguments of shared
library *function* calls, not just kernel-trap system calls.
Something like:
$ truss -o [ output file ] -u'*libc*' [ program ]
There's a more proper way to use -u, but I don't
have a Sun machine at home and I'm too lazy to
check http://docs.sun.com/. :-)
> open("/export/home/rubin/.exrc", O_RDONLY) Err#2 ENOENT
> sigaction(SIGINT, 0xEFFFF210, 0xEFFFF290) = 0
> sigaction(SIGTSTP, 0xEFFFF270, 0xEFFFF2F0) = 0
> dup(4) = 0
> close(4) = 0
> close(-1) Err#9 EBADF
The above close() looks odd, although it's too far
away from the SIGILL to be the cause.
> stat("/var/tmp", 0xEFFFF2F0) = 0
> getpid() = 11718 [11717]
> creat("/var/tmp/Ex0000011718", 0600) = 4
> close(4) = 0
> open("/var/tmp/Ex0000011718", O_RDWR) = 4
> write(1, "1B [ 6 4 ; 1 H", 7) = 7
> sigaction(SIGWINCH, 0xEFFFF0A8, 0xEFFFF128) = 0
> brk(0x000BCB68) = 0
> sigaction(SIGINT, 0xEFFFF048, 0xEFFFF0C8) = 0
> ioctl(2, TCGETS, 0x0009F6D8) = 0
> ioctl(2, TCSETSW, 0x0009F6D8) = 0
> ioctl(2, TCGETS, 0x000B3910) = 0
> ioctl(0, I_STR, 0x0004FEF0) Err#22 EINVAL
> write(1, "1B [ ? 1 h1B =", 7) = 7
> "/tmp/x"write(1, " " / t m p / x "", 8) = 8
> unlink("/var/tmp/Ex0000011718") = 0
> close(4) = 0
> stat("/var/tmp", 0xEFFFD370) = 0
> getpid() = 11718 [11717]
> creat("/var/tmp/Ex0000011718", 0600) = 4
> close(4) = 0
> open("/var/tmp/Ex0000011718", O_RDWR) = 4
Permissions are OK -- creating and opening a file in /var/tmp
returns a file descriptor.
> open("/tmp/x", O_RDONLY) Err#2 ENOENT
> [New file] write(1, " [ N e w f i l e ] ", 12) = 12
> write(1, "1B [ H1B [ J\n ~\n\b ~\n".., 221) = 221
> read(0, 0xEFFFD517, 1) (sleeping...)
Here vi blocks waiting for input (file descriptor
0, the first argument to the read system call, is
stdin).
> read(0, " i", 1) = 1
Here it reads your "insert" command.
> ioctl(0, I_STR, 0x0004FEF0) Err#22 EINVAL
> ~ d", 1) = 1
> ~ ioctl(0, I_STR, 0x0004FEF0) Err#22 EINVAL
Do some ioctl or other on the input descriptor.
> Incurred fault #1, FLTILL %pc = 0x00038B88
Boom. We don't know what happened between the last
ioctl and the SIGILL. The third argument to ioctl
(the address of some structure) is the same for
the last to ioctl calls, which suggests the address
is legitimate. Also, the SIGILL doesn't occur until
after the second ioctl returns; if it were otherwise,
we wouldn't see 'Err#22 EINVAL' as the return code.
On the whole, this is only interesting in so far as
it shows you that /var/tmp has adequate permissions.
Do you have Solaris 8 and the time to use -u and resend
the last 40 lines or so before the SIGILL?
If you don't have Solaris 8 (and you don't want to use
adb to get a stack trace), I'd follow Robert's advice
and check your environment. Perhaps TERM is set to
some odd value.
Regards,
Nicholas Dronen
More information about the SunHELP
mailing list