Re: mimeheaders etc

[Matti Aarnio <mea@nic.funet.fi>]

On Thu, Nov 30, 2000 at 10:48:55PM +0300, Eugene Crosser wrote:
> Matti,
> 
> please inform us when you are satisfied with mimeheaders stuff that
> you are currently working at.  I am eager to check if your recent
> changes really fixed the problem of unlinking directories, but I am
> not sure if current status is safe enough for production environment.

   Me neither.   The fix for directory unlinks is at file

	* scheduler/msgerror.c:
	    Don't try to be clever with cfp->mid field reuse at
	    the slurp()ed instance -- use incoming 'cfpi->mid'.

   The reason I am not happy with the new header code beast is
   that at Solaris I do get core drops, which frankly don't make sense:

(gdb) where
#0  0xef5c6694 in t_splay () from /usr/lib/libc.so.1
#1  0xef5c6504 in t_delete () from /usr/lib/libc.so.1
#2  0xef5c61d8 in realfree () from /usr/lib/libc.so.1
#3  0xef5c69d4 in cleanfree () from /usr/lib/libc.so.1
#4  0xef5c5c30 in _malloc_unlocked () from /usr/lib/libc.so.1
#5  0xef5c5b38 in malloc () from /usr/lib/libc.so.1
#6  0xef5ce310 in strdup () from /usr/lib/libc.so.1
#7  0x18c94 in smtppipestowage (SS=0xefff9388, strbuf=0x38190 "QUIT", 
    syncrp=0x0) at ../../../transports/smtp/smtp.c:3969
#8  0x18d14 in smtpwrite (SS=0xefff9388, saverpt=0, strbuf=0x38190 "QUIT", 
    pipelining=-1, syncrp=0x0) at ../../../transports/smtp/smtp.c:3989
#9  0x130c0 in main (argc=318504, argv=0x4c400)
    at ../../../transports/smtp/smtp.c:727

   well ... they do make sort of sense -- memory corrupts somewhere,
   BUT WHERE !??

   Top-level has variable "task_count" which increments by one for
   every received job.  Lattest core has that count as "17" -- which
   means that the system propably does lots of things before it finds
   the bad combination, and when that bad appears, the culprit is long
   gone...   This needs memory-access debuggers, but Purify license
   doesn't let me to run the D.U.T. at whichever machine I want.

   The code itself is a lot saner when each header is one string, no
   special cases with ``so you are at the end of the string, see if
   the next string begins with a space or tab, if it does, continue
   there'' -- it really, royally, vacuumed things when RFC822 type
   header scanning was needed.

> While I am here, I'd like to remind about two serious known problems:
> 
> 1. If you have virtual domains a.com and b.com both in localnames,
> a.com is also in mail.conf, and a user john@b.com sends mail, then
> if john@a.com exists "envelope from" gets rewritten from john@b.com
> into john@a.com.  This is undesired.

	This question I schedule to next weekend.

> 2. On Solaris (7 in my case), mailbox processes eventually grow to
> hughe size and eat all swap.  I mean, 30 Mb or more per process,
> while the message size is limited to 10 Mb.  Any ideas about that?

	One mimeheaders problem did cause that behaviour over
	past couple days, but other than that, I don't see any
	problem here.   Of course I don't have Sol7/64-bit systems
	where I would have any sort of load. (Not even a test-toy.)
	(Nor I use the '-S' option.  Is the problem there ?)

> Eugene

-- 
/Matti Aarnio	<mea@nic.funet.fi>