servername not honored in imapd.c?

[Simon Matter]

> (Apologies, meant to send this to the list)
>
> ---------- Forwarded message ----------
> Date: Fri, 10 Feb 2006 12:31:59 -0500 (EST)
> From: Steve Huston <huston at astro.princeton.edu>
> To: Simon Matter <simon.matter at ch.sauter-bc.com>
> Subject: Re: servername not honored in imapd.c?
>
> On Fri, 10 Feb 2006, Simon Matter wrote:
>> My current RPM 2.3.1-3 includes updates from CVS of yesterday.
>
> How much testing did you do on it?  I ask because when I saw Ken's
> response, I
> pulled the latest from CVS, built it, brought Cyrus down and installed it.
> Things went okay for awhile (the tls_sessions.db and deliver.db had to be
> deleted, or it didn't want to start) but then every now and then an imapd
> process would start eating up gobs of memory.  Without my noticing a
> couple of
> them ended up taking the whole machine and its swap; after a reboot (and
> unfortunately a mailbox.db restore, and a 'reconstruct -rf user') I was
> able
> to watch now and then when one would lock up.  An strace showed it was
> constantly checking for /var/imap/msg/shutdown, which I found a
> description of
> in the archives, so I don't think that was the problem but I don't know
> what
> it was.  I reverted to the original 2.3.1 and just made the changes in
> imapd.c
> which started this thread, and it's running fine now - so one of the other
> changes seems to have caused the problem.
>
> If there's interest, I might be able to setup the latest CVS code on our
> test
> machine and see if I can provoke it again, but there seemed to be no rhyme
> or
> reason to it - more than one user triggered the problem, and yet the same
> user
> wouldn't trigger it the next time.

Unfortunately I also found a server having problem with it. That's why I
have removed the new package again.
In my case one imapd process was in a loop consuming gigabytes of memory
until it was killed by the kernel. This happened again and again.
I attached an strace to the process but lost it's output for some stupid
reason.
Maybe I can reproduce it later and provide some more information, or Ken
alreasy knows what the problem is.

Simon