[8681] in Athena Bugs
vax 7.3P: attach
daemon@ATHENA.MIT.EDU (Calvin Clark)
Wed Nov 27 11:05:43 1991
Date: Wed, 27 Nov 91 11:05:32 -0500
From: Calvin Clark <ckclark@Athena.MIT.EDU>
To: bugs@Athena.MIT.EDU
Cc: bug-attach@Athena.MIT.EDU
Reply-To: ckclark@mit.edu
System name: hal-2000
Type and version: CVAXSTAR 7.3P (5 update(s) to same version)
Display type: SM
What were you trying to do?
Run /etc/athena/reactivate -detach.
What's wrong:
attach left a large (756K) core dump after a memory fault. Here
is the section of the reactivate output where it happened:
fsid: windowmanagers ignored (operation not supported on AFS)
fsid: pit-manager:/ua mappings purged
/etc/athena/reactivate: 24072 Memory fault - core dumped
detach: x11r5 detached
detach: aeneas:/gnu detached
(Note: I had an abnormally large number of filesystems attached before
running reactivate (59) and most of them were NFS.)
Here is the stack trace from gdb:
(gdb) where
#0 0x6797 in add_cache_ent (637552402, 174336, 13, 2147474224)
#1 0x69ec in rpc_create (637552402, 2147474224)
#2 0x70c9 in nfsid (487844, 637552402, 9, 1, 486820, 0, 0)
#3 0x88c in nfsidcmd (3, 2147476732)
#4 0x3a5 in main (3, 2147476732, 2147476748)
The core dump is in /mit/coredumps/attach.core.ckclark.911127.Z
This occured while doing on fsid -p -a, and I have determined from the
core dump that it died with a memory fault trying to unmap to
aeneas:/gnu, since that's what 637552402 is. aeneas:/gnu was the
58th filesystem it tried to unmap, if that makes a difference.
I have examined the values of the arguments passed to add_cache_ent, and
have found nothing unexpected.
What should have happened:
I don't know. I am not sure why attach had so much in memory.
Please describe any relevant documentation references:
nfsid (1)
