On Mon, 6 Jan 2003, Henrique de Moraes Holschuh wrote:
> I suggest the assert in Gerd's patch to be moved to before the if clause.
> That way, we catch any other bug that triggers that assert.
Actually, based on discussions with Larry I'm pretty sure Gerd's patch is
now extra code that doesn't ad
On Mon, 06 Jan 2003, Rob Siemborski wrote:
> I've committed/credited this as well.
By doing that you fixed the hole Gerd's workaround was initially added for
:-)
I suggest the assert in Gerd's patch to be moved to before the if clause.
That way, we catch any other bug that triggers that assert.
I've committed/credited this as well.
Thanks,
-Rob
On Sun, 5 Jan 2003, Henrique de Moraes Holschuh wrote:
> On Sun, 05 Jan 2003, Henrique de Moraes Holschuh wrote:
> > On Sun, 05 Jan 2003, Gerd v. Egidy wrote:
> > > > The attached patch fixes this.
>
> The attached patch fixes the bug in prot_fl
Both of these patches have been committed and credited.
On to look at Henrique's addition
Thanks,
-Rob
On Sun, 5 Jan 2003, Gerd v. Egidy wrote:
> > The attached patch fixes this.
>
> Just a cosmetic fix - the defined prot_putc now returns EOF in case of error.
>
-=-=-=-=-=-=-=-=-=-=-=-=-=
On Sun, 05 Jan 2003, Henrique de Moraes Holschuh wrote:
> On Sun, 05 Jan 2003, Gerd v. Egidy wrote:
> > > The attached patch fixes this.
The attached patch fixes the bug in prot_flush. It also adds an assert that
protects the code from another potentially letal bug.
Gerd's patch fixes another iss
On Sun, 05 Jan 2003, Gerd v. Egidy wrote:
> > The attached patch fixes this.
Looking through the code, it looks like it must never happen for cnt to be
zero outside of prot_*, for write streams.
IMHO proper asserts should be added to the #define macros to guard against
this (it looks like there i
> The attached patch fixes this.
Just a cosmetic fix - the defined prot_putc now returns EOF in case of error.
diff -r -u cyrus-imapd-2.1.11.orig/lib/prot.c cyrus-imapd-2.1.11/lib/prot.c
--- cyrus-imapd-2.1.11.orig/lib/prot.c Mon Oct 21 22:44:22 2002
+++ cyrus-imapd-2.1.11/lib/prot.c Sat Jan 4 2
Hi,
since some popular client (we know which one ;) sometimes just kicks a
connection instead of gracefully closing it we have a decent number of broken
pipe signals sent to our imapds.
since our upgrade from 2.0 to 2.1.11 this was often followed by a segfault of
the process who just got the b
