[7004] in Athena Bugs
vax 7.2P: xmh
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Jan 31 15:23:19 1991
Date: Thu, 31 Jan 91 15:22:56 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: lavin@ATHENA.MIT.EDU
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: bugs[6986]
I will forward your message, unaltered, to the X consortium :-).
However, I have a few comments about it.
Date: Tue, 29 Jan 91 19:47:48 EST
From: Anne R. LaVin E40-343A x3-0115 <lavin@ATHENA.MIT.EDU>
System name: laika
Type and version: CVAXSTAR 7.2P (1 update(s) to same version)
Display type: SM
What were you trying to do?
Yes, I know, Athena isn't responsible for bugs in xmh, and will just
forward the mail on to the X consortium or something. Fine. Realize
that the annoyed tone is directed at whoever is actually responsible
for the silly thing, not Athena.
Xmh's user-interface featurefullness (great word, eh?) has just been
surpassed by its ability to thoroughly annoy me. I have switched to
mh-rmail mode in emacs. (If that is suitably annoying I suspect I
will just stop picking up my email. Or quit, since it is, after all,
my job to deal with lots of mail.)
Several times over the last week, xmh has just up and quit on me -- no
error message, no core dump, no NOTHING. Just gone. I cannot
reproduce it reliably, but it appears to happen when I am in the
process of editing and saving existing messages in a folder (i.e. I
click on the "edit message" menu item under "view" and then try to
save the message back when I'm done.
I find this hard to believe. You have coredumpsize unlimited? You
didn't even get a "cannot perform malloc" error or anything like that?
Very strange.
And then there's what happens when my AFS tokens expire. I'm sure you
know about that, so I won't bother going into details. It would be
nice if it could check, first, like it does with Kerberos tickets,
instead of just dying with all sorts of fun error messages in my
console about "not able to save file," or something.
Yeah, they already know about the fact that there are various
situations when xmh should just print a warning, or resynchronize the
.xmhcache files (like if you "inc" outside of xmh while it is running,
or delete a message using rmm), rather than exiting. I don't know how
long it's going to take for them to fix it. As I've been told by
Swick, libraries are a higher priority than clients.
And finally, today, it just decided to hang. No errors, nothing,
just completely frozen. It wouldn't refresh, and sat there eating up
96% of my CPU until I killed it 10 minutes later. (I let it hang
around for a while hoping it would come back.) I wasn't doing
anything that I hadn't done zillions of times before, namely, pasting
text from an emacs buffer into the xmh editing window.
If this happens again, please kill -STOP the xmh process and gcore it
to get a coredump, so we can see where it's looping.
Jonathan Kamens
Project Athena Quality Assurance
