[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mimeheaders etc
On Thu, Nov 30, 2000 at 10:48:55PM +0300, Eugene Crosser wrote:
> 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
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:
#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)
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 email@example.com sends mail, then
> if firstname.lastname@example.org exists "envelope from" gets rewritten from email@example.com
> into firstname.lastname@example.org. 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 ?)
/Matti Aarnio <email@example.com>