Henrique de Moraes Holschuh wrote: >On Wed, 15 May 2002, Scott Russell wrote: > > >>On Wed, May 15, 2002 at 10:35:04AM -0300, Henrique de Moraes Holschuh wrote: >> >> >>>I don't know about all the other patches, though. I have included the >>>safe_flock patches, and I *may* include the alarm and locking stuff in >>>master-avail.diff later, but I must study and understand it first. >>> >>> >>Are the patches TLS sane / tested? At one point I remember reading >> >> > >The ones I am including in Debian are. No TLS is _not_ an option IMHO. > The TLS issue was simply required to work around a memory corruption bug. The patches all work correctly with TLS, as long as you remove the ' && !imapd_in->tls_conn' bits in imapd.c and pop3d.c.
These extra tests are nothing to do with the other patches. The problem is that imapd_in et al sometimes get overwritten, causing prot_flush and prot_fill to result in a segfault when they are call during shut_down() or imapd_reset(). Therefore we wanted some way of checking whether imapd_in was still sane, and we happened to pick to check that ->tls_conn==0. A better approach would be to make the first element of the record a known constant and check for that. An even better approach would be to work out why the structure is getting corrupted in the first place! To clarify--the memory corruption problem occurs regardless of whether the other patches are present (in our environment at least), and needs to be worked around regardless of whether the other patches are present. The issues are completely independent. The memory corruption bug is something we see every few thousand connections under Linux 2.4.18 with Cyrus 2.1.3 in a mixed client high load environment.
