[24948] in SIPB bug reports
Re: exmh panics 9.4.17 Solaris
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Sep 20 15:26:08 2005
From ghudson@MIT.EDU Tue Sep 20 19:26:07 2005
Return-Path: <ghudson@MIT.EDU>
Delivered-To: bug-sipb-mtg@CHARON.mit.edu
Received: (qmail 6922 invoked from network); 20 Sep 2005 19:26:07 -0000
Received: from biscayne-one-station.mit.edu (18.7.7.80)
by charon.mit.edu with SMTP; 20 Sep 2005 19:26:07 -0000
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j8KJQ3BA011907;
Tue, 20 Sep 2005 15:26:03 -0400 (EDT)
Received: from equal-rites.mit.edu (EQUAL-RITES.MIT.EDU [18.18.1.59])
(authenticated bits=56)
(User authenticated as ghudson@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j8KJPxhC027889
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 20 Sep 2005 15:26:00 -0400 (EDT)
Received: (from ghudson@localhost) by equal-rites.mit.edu (8.12.9)
id j8KJPxVN000932; Tue, 20 Sep 2005 15:25:59 -0400
Subject: Re: exmh panics 9.4.17 Solaris
From: Greg Hudson <ghudson@MIT.EDU>
To: John Hawkinson <jhawk@mit.edu>
Cc: bugs@mit.edu, bug-sipb@mit.edu
In-Reply-To: <200509201851.j8KIpCuJ016073@bart-savagewood.mit.edu>
References: <200509201851.j8KIpCuJ016073@bart-savagewood.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Sep 2005 15:25:59 -0400
Message-Id: <1127244359.332.21.camel@equal-rites.mit.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4
X-Spam-Score: 1.589
X-Spam-Level: * (1.589)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Well, I just had a fascinating series of test results using systest on
my test machine:
% exmh
Segmentation fault
% exmh
Segmentation fault
% gdb --args /afs/sipb/project/tcl/wish -f /mit/sipb/bin/exmh
(Inside gdb, exmh appears to function normally, although I didn't know
it was normal to spew an inc display to stdout)
% exmh
/mit/sipb/arch/sun4x_510/bin/exmh: Permission denied.
% exmh
/mit/sipb/arch/sun4x_510/bin/exmh: Permission denied.
% ls -l /afs/sipb/project/tcl/wish
lrwxr-xr-x 1 17069 root 8 Jan 20 1996 /afs/sipb/project/tcsh/wish -> bin/wish
% ls -l /afs/sipb/project/tcl/bin/wish
lrwxr-xr-x 1 4945 mit 7 Jun 4 2004 /afs/sipb/project/tcl/bin/wish ->
(In the real world, this symlink points to "wish8.4")
So we're seeing three different manifestations at different times:
* exmh exiting with a segmentation fault
* Kernel panics as jhawk reported
* Corrupting the value of
the /afs/sipb/project/tcl/arch/sun4x_59/bin/wish symlink, resulting in a
"Permission denied" error as the shell tries to execute the
directory /afs/sipb/project/tcl/arch/sun4x_59/bin.
One possible area to look at is the AFS @sys compatibility
code. /afs/sipb/project/tcl/bin is a symlink to arch/@sys/bin, and
there is no arch/sun4x_510, so AFS is falling back to arch/sun4x_59.
But honestly, the memory corruption could be happening anywhere in the
exmh execution path.
