nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (12/21/89)
I've recently upgraded from a Sun3 to Sun4, and while Andrew (R4 beta release, patchlevel 6) seems to be working pretty well in general, I'm seeing an oddity that I don't think I've seen mentioned previously. The oddity is this: Sometimes, when AMS reads in new incoming mail, it builds the "captions" wrong -- in particular, it completely omits the sender's name from the caption, which therefore consists only of Date Subject - (size) Now, the oddest part of this is that it is not consistent, but that it affects all incoming mail read in a single chunk. That is, if I have ten new pieces of mail, either all ten will have "correct" captions or none of them will. So the variance doesn't seem to be on a per-mail basis, but on a per-mailbox-checking-incident basis. I haven't had a chance to probe the code yet -- it looks painful, since it isn't reproducible -- but I was wondering if anyone else had seen this problem or had any ideas about how to fix it. Cheers. -- Nathaniel
Richard.Draves@CS.CMU.EDU (12/22/89)
I see this problem off and on using messages on my IBM RT. I am pretty sure I have seen it using the latest version, 7.14/14.1, although it isn't a common occurrence. Rich
wdc@ATHENA.MIT.EDU (Bill Cattey) (12/22/89)
I too had this happen to me on a VAX exactly once. (It also occured about the same time that I failed to receive a message, and heard about the mailing in the hallway and got a re-transmission.) Let's keep our eyes open and see if we ever track this down... -wdc
janssen@parc.xerox.com (Bill Janssen) (12/22/89)
I see it here on SparcStations. With the X11R3 release (which I still normally use for mail) it has only happened once, while reading a spool file of earthquake-delayed messages and replies, that had already been partially processed with /usr/ucb/Mail. With the X11R4 messages, it seems to happen almost randomly. It seems particularly noticeable on bulletin boards. Bill
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (12/22/89)
I think I've figured it out, but I can't test it just now. The entire bug would be explained perfectly if the "Template" parameter passed in to the BuildCaption function had not been initialized properly. This appears to be the case in at least one important place -- ams/libs/ms/newmail.c, line 147. A fix would be to add a line (line 139 looks like a good place) that says: CaptionTemplateList[i].basictype = BASICTEMPLATE_NORMAL; I think this will fix the bug, but it will be a while (like, next decade) before I can test it -- if someone else is motivated to test it, you should report the results. However, I'm pretty sure this is the bug. Someone should probably also grep for all the other uses of BuildCaption to make sure all the template parameters are properly initialized. -- Nathaniel PS -- all will work fine if the structure is initially zero, which may explain why it ususally works for most people. -- NB
mss+@ANDREW.CMU.EDU (Mark Sherman) (12/22/89)
Excerpts from mail: 22-Dec-89 Re: Sun4 AMS oddity Nathaniel Borenstein@thu (402+0) >> Excerpts from mail: 21-Dec-89 Re: Sun4 AMS oddity Mark >> Sherman@andrew.cmu. (147) >> You might have hit the font cache bug. That is one effect. DOes the name >> return when you select the message (thereby using another font?) >> -Mark > No, this has nothing to do with ATK or X, I think -- the caption is > actually being constructed wrong. I'm sure it is a SPARC-specific bug > in the messageserver code. -- NB If it really only occurs on Sparcstations, then I have a hunch. Nearly all the SPARC specific problems like this in the past have resulted from a misdeclaration/use of the union: union environmentcontents { struct style *style; struct viewref *viewref; }; Typically, one side "knows" that it is really a struct style * while the other side is declaring the full union. Hence it is passed one way and expected the other (I believe the usual scenario is that the argument is passed as a union but the parameter is declared as a pointer -- isn't C type checking wonderful.) Apparently, union environmentcontents and struct style * are not interchangable on Sparcstations but works just fine on Sun-3s and RTs. -Mark
cfe+@ANDREW.CMU.EDU ("Craig F. Everhart") (12/23/89)
Nathaniel's suggested change looks good, but is a change to code that's
surrounded by ``#if 0'' and ``#endif''; it's the old code that deals
with .MS.spec files, which was commented out that way.
I couldn't find any obvious offenders in the BuildCaption clients, but
I've added some bullet-proofing just in case; in
ams/libs/ms/{apndfile.c,bldcapt.c,merge.c,submsg.c}, templates were
bzero'ed before use rather than having their fields set individually.
Craignsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (12/23/89)
Sigh... so I've debugged code that isn't even compiled any more. I guess that's what happens when you've been away for this long... I guess that both the misaligned-union and the uninitialized-template hypotheses are both still reasonable possibilities. Sorry to have missed the ifdef's, and Happy Holidays to all. -- Nathaniel
wdc@ATHENA.MIT.EDU (Bill Cattey) (12/28/89)
Excerpts from mail: 22-Dec-89 Re: Sun4 AMS oddity Nathaniel Borenstein@THU (333) > I guess that both the misaligned-union and the uninitialized-template > hypotheses are both still reasonable possibilities. Do either of these apply also to VAXEN? I mentioned in a previous post that I had this problem occur on a vax. If only one of these possibilities occur on a vax, we have narrowed our search. If neither of them occur, we're looking in the wrong place. -wdc