Bug#200641: glibc gmtime() broken for 64bit time_t (in arch=alpha)
On Thu, 21 Oct 2004, GOTO Masanori wrote:
> > On Wed, 09 Jul 2003, Tom Fernandes wrote:
> > > +#if 0
> > > /* Some gmtime() implementations are broken and will return
> > > * NULL for time_ts larger than 40 bits even on 64-bit platforms
> > > * so we'll just cap it at 40 bits */
> > > if(bits > 40) bits = 40;
> > > +#endif
>
> Could you explain what the bug is? If you have spare time to make
> sample program to reproduce this issue, please let us know.
See the attached .c and .h files which cause the trouble in Cyrus.
The problematic function is mkgmtime. If it returns NULL, Cyrus refuses the
message on the grounds that something is fishy, and that generated the bug
reports on archs such as Alpha.
#244922: cyrus21-imapd: invalid date with pine imap access
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244922&archive=yes
I have also attached a few emails from the cyrus-users ML that also give
some details on the problem. Re-reading them, I see that the current
"workaround" of capping at 40 bits will let us work with years from -32873
to 36812, which is quite enough as far as I am concerned ;-) But let's
get back to the gmtime() issue...
As I understand it, Cyrus expected (before we added the cap at 40 bits) that
if you give it a time_t that is 64-bits long, it can use all 64 bits
meaningfully and won't overflow tm->year.
How that plays with the following comment in gmtime(3), I don't know:
The gmtime() function converts the calendar time timep to
broken-down time representation, expressed in Coordinated Universal
Time (UTC). It may return NULL when the year does not fit into an
integer.
What size is an integer on alpha? singed 64 bits? If so, how could gmtime
be overflowing the year?
Dates that are reported to be problematic (see attached files):
9-Aug-2002 11:55:32 -0400
26-Mar-2003 11:12:21 +0100
(but I think any date will do, actually).
Now, reading it all to send you this email, I am not so sure glibc gmtime is
broken, since Cyrus *is* assuming that "time_t has 64 bits imples that an
int also does" in that code, which is dubious at best.
OTOH, if an int has 64 bits on alpha, glibc gmtime is to allow 64bits worth
of tm->year before it returns NULL...
So, if int on alpha is 32 bits, we have no bug and I apologise for not
doing the full homework before, and trusting the word from others that it
was a gmtime bug.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
/* mkgmtime.c - make time corresponding to a GMT timeval struct
$Id: mkgmtime.c,v 1.8 2003/04/07 16:52:45 rjs3 Exp $
* Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The name "Carnegie Mellon University" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For permission or any other legal
* details, please contact
* Office of Technology Transfer
* Carnegie Mellon University
* 5000 Forbes Avenue
* Pittsburgh, PA 15213-3890
* (412) 268-4387, fax: (412) 268-7395
* tech-transfer@andrew.cmu.edu
*
* 4. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by Computing Services
* at Carnegie Mellon University (http://www.cmu.edu/computing/)."
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE
* FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
* AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
*
*/
/*
* Copyright (c) 1987, 1989, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Arthur David Olson of the National Cancer Institute.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
** Adapted from code provided by Robert Elz, who writes:
** The "best" way to do mktime I think is based on an idea of Bob
** Kridle's (so its said...) from a long time ago. (mtxinu!kridle now).
** It does a binary search of the time_t space. Since time_t's are
** just 32 bits, its a max of 32 iterations (even at 64 bits it
** would still be very reasonable).
*/
#include <time.h>
#ifndef WRONG
#define WRONG (-1)
#endif /* !defined WRONG */
static int
tmcomp(atmp, btmp)
register const struct tm * const atmp;
register const struct tm * const btmp;
{
register int result;
if ((result = (atmp->tm_year - btmp->tm_year)) == 0 &&
(result = (atmp->tm_mon - btmp->tm_mon)) == 0 &&
(result = (atmp->tm_mday - btmp->tm_mday)) == 0 &&
(result = (atmp->tm_hour - btmp->tm_hour)) == 0 &&
(result = (atmp->tm_min - btmp->tm_min)) == 0)
result = atmp->tm_sec - btmp->tm_sec;
return result;
}
time_t
mkgmtime(tmp)
struct tm * const tmp;
{
register int dir;
register int bits;
register int saved_seconds;
time_t t;
struct tm yourtm, *mytm;
yourtm = *tmp;
saved_seconds = yourtm.tm_sec;
yourtm.tm_sec = 0;
/*
** Calculate the number of magnitude bits in a time_t
** (this works regardless of whether time_t is
** signed or unsigned, though lint complains if unsigned).
*/
for (bits = 0, t = 1; t > 0; ++bits, t <<= 1)
;
/*
** If time_t is signed, then 0 is the median value,
** if time_t is unsigned, then 1 << bits is median.
*/
t = (t < 0) ? 0 : ((time_t) 1 << bits);
/* Some gmtime() implementations are broken and will return
* NULL for time_ts larger than 40 bits even on 64-bit platforms
* so we'll just cap it at 40 bits */
if(bits > 40) bits = 40;
for ( ; ; ) {
mytm = gmtime(&t);
if(!mytm) return WRONG;
dir = tmcomp(mytm, &yourtm);
if (dir != 0) {
if (bits-- < 0)
return WRONG;
if (bits < 0)
--t;
else if (dir > 0)
t -= (time_t) 1 << bits;
else t += (time_t) 1 << bits;
continue;
}
break;
}
t += saved_seconds;
return t;
}
/* mkgmtime.h -- make a time_t from a gmtime struct tm
$Id: mkgmtime.h,v 1.5 2003/02/13 20:15:41 rjs3 Exp $
* Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The name "Carnegie Mellon University" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For permission or any other legal
* details, please contact
* Office of Technology Transfer
* Carnegie Mellon University
* 5000 Forbes Avenue
* Pittsburgh, PA 15213-3890
* (412) 268-4387, fax: (412) 268-7395
* tech-transfer@andrew.cmu.edu
*
* 4. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by Computing Services
* at Carnegie Mellon University (http://www.cmu.edu/computing/)."
*
* CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
* THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE
* FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
* AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
*/
#ifndef INCLUDED_MKGMTIME_H
#define INCLUDED_MKGMTIME_H
#ifndef P
#ifdef __STDC__
#define P(x) x
#else
#define P(x) ()
#endif
#endif
#include <time.h>
extern time_t mkgmtime P((struct tm * const tmp));
#endif /* INCLUDED_MKGMTIME_H */
>From owner-info-cyrus@lists.andrew.cmu.edu Wed Mar 26 10:47:37 2003
X-Original-To: hmh@khazad-dum.debian.net
From: Jeremy Rumpf <jrumpf@heavyload.net>
To: Oliver Pitzeier <o.pitzeier@uptime.at>
Subject: Re: Signaled to death by 11
Date: Wed, 26 Mar 2003 08:27:29 -0500
Cc: Info-cyrus@lists.andrew.cmu.edu
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
Status: RO
On Wednesday 26 March 2003 05:35 am, Oliver Pitzeier wrote:
> Oliver Pitzeier wrote:
> > > Rob Siemborski wrote:
> > > > > Copying mails between two imap-servers is normally no
> > > > > problem and works with all my servers, except this one...
> > > > >
> > > > > Any ideas?
> > > >
> > > > Do you have a protocol trace of what outlook is feeding cyrus?
> > > > Alternatively, do you have a backtrace of the core dump?
>
> Here we go:
>
> DONE
> 001S OK Completed
> 001Y APPEND "INBOX" (\Seen) "26-Mar-2003 11:12:21 +0100" {8167}
>
> This seems right for me.
>
> Best regards,
> Oliver
This has been on this list in the past, this post is on an older release, but
is the problem is the same. The imap server dumps when a message from Outlook
or Outlook Express is copied to it. Machine is an older alpha ev5.6. Here's a
recap:
-------------------------------------------------------------------
From: Jeremy Rumpf <jrumpf@heavyload.net>
To: info-cyrus@lists.andrew.cmu.edu
Date: 08/19/02 15:05 pm
Recompiled cyrus with debug support, reproduced the segv, loaded the core file
into gdb. Here's the goodies:
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alpha-redhat-linux"...
(gdb) core-file core
Core was generated by `imapd -s'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libsasl2.so.2...done.
Loaded symbols for /usr/lib/libsasl2.so.2
Reading symbols from /lib/libssl.so.2...done.
Loaded symbols for /lib/libssl.so.2
Reading symbols from /lib/libcrypto.so.2...done.
Loaded symbols for /lib/libcrypto.so.2
Reading symbols from /lib/libdb-3.2.so...done.
Loaded symbols for /lib/libdb-3.2.so
Reading symbols from /lib/libresolv.so.2.1...done.
Loaded symbols for /lib/libresolv.so.2.1
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /lib/libnsl.so.1.1...done.
Loaded symbols for /lib/libnsl.so.1.1
Reading symbols from /lib/libc.so.6.1...done.
Loaded symbols for /lib/libc.so.6.1
Reading symbols from /lib/libdl.so.2.1...done.
Loaded symbols for /lib/libdl.so.2.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done.
Loaded symbols for /usr/lib/sasl2/libsasldb.so.2
Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done.
Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2
Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done.
Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2
Reading symbols from /usr/lib/sasl2/libotp.so.2...done.
Loaded symbols for /usr/lib/sasl2/libotp.so.2
Reading symbols from /usr/lib/sasl2/libplain.so.2...done.
Loaded symbols for /usr/lib/sasl2/libplain.so.2
Reading symbols from /lib/libcrypt.so.1.1...done.
Loaded symbols for /lib/libcrypt.so.1.1
Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done.
Loaded symbols for /usr/lib/sasl2/libanonymous.so.2
Reading symbols from /usr/lib/sasl2/liblogin.so.2...done.
Loaded symbols for /usr/lib/sasl2/liblogin.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_ldap.so.2...done.
Loaded symbols for /lib/libnss_ldap.so.2
Reading symbols from /usr/lib/sasl/libanonymous.so...done.
Loaded symbols for /usr/lib/sasl/libanonymous.so
Reading symbols from /usr/lib/sasl/libcrammd5.so...done.
Loaded symbols for /usr/lib/sasl/libcrammd5.so
Reading symbols from /usr/lib/sasl/libdigestmd5.so...done.
Loaded symbols for /usr/lib/sasl/libdigestmd5.so
Reading symbols from /usr/lib/sasl/liblogin.so...done.
Loaded symbols for /usr/lib/sasl/liblogin.so
Reading symbols from /lib/libpam.so.0...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /usr/lib/sasl/libplain.so...done.
Loaded symbols for /usr/lib/sasl/libplain.so
#0 0x12006cf0c in tmcomp (atmp=0x0, btmp=0x11fffddd0) at mkgmtime.c:102
102 if ((result = (atmp->tm_year - btmp->tm_year)) == 0 &&
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 0x12006cf0c in tmcomp (atmp=0x0, btmp=0x11fffddd0) at mkgmtime.c:102
#1 0x12006d0e4 in mkgmtime (tmp=0x11fffde60) at mkgmtime.c:138
#2 0x120020c78 in getdatetime (date=0x11fffe0a0) at imapd.c:6870
#3 0x1200104d4 in cmd_append (tag=0x1201a24c0 "000E", name=0x1201a25a0
"INBOX") at imapd.c:2382
#4 0x120009e20 in cmdloop () at imapd.c:876
#5 0x120009158 in service_main (argc=2, argv=0x11ffff908, envp=0x11ffff920)
at imapd.c:665
#6 0x120006a4c in main (argc=2, argv=0x11ffff908, envp=0x11ffff920) at
service.c:464
#7 0x200003a70ec in __libc_start_main (main=0x1200060a0 <main>, argc=2,
ubp_av=0x11ffff908, init=0x120005890 <_init>, fini=0x2000002e788
<_dl_debug_mask>, rtld_fini=0xa9,
stack_end=0x11ffff8f0) at ../sysdeps/generic/libc-start.c:129
(gdb)
-------------------------------------------------------------------
From: Jeremy Rumpf <jrumpf@heavyload.net>
To: info-cyrus@lists.andrew.cmu.edu
Date: 08/19/02 13:49 pm
I've noticed a problem in imapd when interacting with Outlook/Outlook express
clients via imap.
The outcome of the problem is imapd catching a sigsegv when copying
(appending) messages to a folder. I originally uncovered the problem, after
installing cyrus, by attempting to copy all my local messages to cyrus imapd
by dragging them from the local inbox to the imap inbox on cyrus. In doing
so, Outlook opens an error box stating, "You message could not be uploaded to
the imap server. The server refused to accept it". This is consistent with
both Outlook 2000 (9.0.0.2711) and Outlook Express 6 (6.00.2600). The master
log simply states:
Aug 19 09:49:31 imapd[2419]: login: rayovac.foo.net[192.168.1.1] m1
plaintext+TLS
Aug 19 09:49:31 master[991]: process 2419 exited, signaled to death by 11
Further more, the cyrus telemetry logs show the following:
---------- m1 Mon Aug 19 09:49:11 2002
>1029764951>0001 OK User logged in
<1029764951<0002 STATUS "INBOX" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX (MESSAGES 0 UNSEEN 0)
0002 OK Completed
<1029764951<0003 STATUS "INBOX/bar.us" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX/bar.us (MESSAGES 0 UNSEEN 0)
0003 OK Completed
<1029764951<0004 STATUS "INBOX/foo.net" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX/foo.net (MESSAGES 0 UNSEEN 0)
0004 OK Completed
<1029764951<0005 STATUS "INBOX/foo.net/cyrus-list" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX/foo.net/cyrus-list (MESSAGES 38 UNSEEN 14)
0005 OK Completed
<1029764951<0006 STATUS "INBOX/foo.net/xfree-list" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX/foo.net/xfree-list (MESSAGES 34 UNSEEN 27)
0006 OK Completed
<1029764951<0007 STATUS "INBOX/foo.com" (MESSAGES UNSEEN)
>1029764951>* STATUS INBOX/foo.com (MESSAGES 2 UNSEEN 0)
0007 OK Completed
<1029764951<ZZZZ LOGOUT
>1029764951>* BYE LOGOUT received
ZZZZ OK Completed
---------- m1 Mon Aug 19 09:49:31 2002
>1029764971>000D OK User logged in
<1029764971<000E APPEND "INBOX" (\Seen) " 9-Aug-2002 11:55:32 -0400" {10132}
In addition to the cyrus telemetry logs. I've also captured the following
snipped from Outlook 6 by enabling imap logging:
Microsoft Internet Messaging API 6.00.2600.0000
IMAP Log started at 08/19/2002 09:49:58
IMAP: 09:49:58 [db] Connecting to 'foo.net' on port 993.
IMAP: 09:49:58 [db] OnNotify: asOld = 0, asNew = 4, ae = 0
IMAP: 09:49:58 [db] Negotiating secure connection with 'Microsoft Unified
Security Protocol Provider'.
IMAP: 09:49:58 [db] OnNotify: asOld = 4, asNew = 6, ae = 2
IMAP: 09:49:58 [db] OnNotify: asOld = 6, asNew = 6, ae = 4
IMAP: 09:49:58 [db] OnNotify: asOld = 6, asNew = 5, ae = 2
IMAP: 09:49:58 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 09:49:58 [rx] * OK IMAP4 Ready rayovac.foo.net
IMAP: 09:49:58 [tx] 000C CAPABILITY
IMAP: 09:49:58 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 09:49:58 [rx] * CAPABILITY IMAP4 IMAP4REV1 LITERAL+
IMAP: 09:49:58 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 09:49:58 [rx] 000C OK CAPABILITY
IMAP: 09:49:58 [tx] LOGIN command sent
IMAP: 09:49:59 [db] OnNotify: asOld = 5, asNew = 5, ae = 3
IMAP: 09:49:59 [rx] 000D OK User logged in
IMAP: 09:49:59 [tx] 000E APPEND "INBOX" (\Seen) " 9-Aug-2002 11:55:32 -0400"
{10132}
IMAP: 09:49:59 [db] Connection to 'foo.net' closed.
IMAP: 09:49:59 [db] OnNotify: asOld = 5, asNew = 0, ae = 5
IMAP: 09:49:59 [db] ERROR: "Your server has unexpectedly terminated the
connection. Possible causes for this include server problems, network
problems, or a long period of inactivity.", hr=2148322319
So perhaps it's something with the way Outlook issues the APPEND statement?
I've performed the same identical steps using Kmail as the client with
complete success. Dragging and dropping a message in a local folder to a
folder served by cyrus imapd using Kmail produces the following telemetry
log:
>1029778580>2374 OK User logged in
<1029778580<2375 LIST "" "%"
>1029778580>* LIST (\HasChildren) "/" "INBOX"
2375 OK Completed (0.005 secs 7 calls)
<1029778580<2376 LIST "" "INBOX"
>1029778580>* LIST (\HasChildren) "/" "INBOX"
2376 OK Completed (0.003 secs 7 calls)
<1029778580<2377 LIST "" "INBOX/%"
>1029778580>* LIST (\HasNoChildren) "/" "INBOX/bar.us"
* LIST (\HasChildren) "/" "INBOX/foo.net"
* LIST (\HasNoChildren) "/" "INBOX/foo.com"
2377 OK Completed (0.002 secs 6 calls)
<1029778580<2378 LIST "" "INBOX/foo.net"
>1029778580>* LIST (\HasChildren) "/" "INBOX/foo.net"
2378 OK Completed (0.002 secs 4 calls)
<1029778580<2379 LIST "" "INBOX/foo.net/%"
>1029778580>* LIST (\HasNoChildren) "/" "INBOX/foo.net/cyrus-list"
* LIST (\HasNoChildren) "/" "INBOX/foo.net/xfree-list"
2379 OK Completed (0.001 secs 3 calls)
<1029778595<2380 NOOP
>1029778595>2380 OK Completed
<1029778603<2381 LIST "" "INBOX"
>1029778603>* LIST (\HasChildren) "/" "INBOX"
2381 OK Completed (0.002 secs 7 calls)
<1029778603<2382 APPEND "INBOX" (\SEEN) {3421}
>1029778603>+ go ahead
Perhaps something with the datastamp, in the append call?
Outlook: APPEND "INBOX" (\Seen) " 9-Aug-2002 11:55:32 -0400" {10132}
Kmail : APPEND "INBOX" (\SEEN) {3421}
Details on the cyrus server are:
cyrus-imapd-2.1.5
cyrus-sasl-2.1.7
-------------------------------------------------------------------
>From owner-info-cyrus@lists.andrew.cmu.edu Wed Mar 26 12:24:15 2003
X-Original-To: hmh@khazad-dum.debian.net
From: Jeremy Rumpf <jrumpf@heavyload.net>
To: Oliver Pitzeier <o.pitzeier@uptime.at>
Subject: Re: Signaled to death by 11
Date: Wed, 26 Mar 2003 09:51:01 -0500
Cc: Info-cyrus@lists.andrew.cmu.edu
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
Status: RO
On Wednesday 26 March 2003 08:57 am, Oliver Pitzeier wrote:
> Jeremy Rumpf wrote:
> > This has been on this list in the past, this post is on an
> > older release, but is the problem is the same. The imap server
> > dumps when a message from Outlook or Outlook Express is copied
> > to it. Machine is an older alpha ev5.6. Here's a recap:
>
> [ ... ]
>
> Thanks a lot Jeremy. But nobody had a solution, I'm I correct? Because the
> problem still exists... I do now have a solution wich is not fine... Maybe
> one of the cyrus developers helps me to do it better...
>
> Best regards,
> Oliver
Actually, I think someone a while ago had come up with a solution. I'm not
sure how proper it is, you can decide. Here's a copy of the post from Fritz
Test <Fritz.Test@bam.de> :
Recently I ran into the same trouble (signalled to death by 11) with
Outlook Clients moving mails to a Cyrus folder as Jeremy described in
his mail on the info-cyrus list in August last year (see URL above).
I'm using Simon Matter's last SRPM Packages on COMPAQ DS20, RedHat Linux
7.2/Alpha.
With help of the analysis of Jeremy (Thanks) I patched the function
mkgmtime, such that it works for me now. The problem is, that gmtime(&t)
returns a null pointer for my 64-bit system if t is out of some range. I
don't know exactly what range, but I assume that the generated value for
the year must fit in 32 bits?.
Here's a snipped of my code in mkgmtime.c
-----------------------------------------------
/*
** If time_t is signed, then 0 is the median value,
** if time_t is unsigned, then 1 << bits is median.
*/
t = (t < 0) ? 0 : ((time_t) 1 << bits)
;
/* Patch begin */
/*
** On my 32-bit Debian GNU/Linux 3.0 AMD K6 PC, the algorithm
** converges in a range
** from
** 1901-12-13 20:46:00 GMT -> -2147483640
** to
** 2038-01-19 03:14:07 GMT -> 2147483647
*/
/*
** It segfaults on RedHat 7.2/Alpha if bits > 56, since gmtime (&t)
** returns null pointer.
** Hence, set bits to a resonable value <= 56.
**
** Setting, e.g. bits=40, the algorithm converges in a range
** from
** -32873-11-12 23:24:00 GMT -> -1099511627760
** to
** 36812-02-20 00:36:59 GMT -> 1099511627819
*/
if (bits > 40) {
bits = 40;
}
/* patch end */
for ( ; ; ) {
prt (t);
fprintf (stderr, " ");
----------------------------------------------------------
Hope this helps
Tom
Reply to: