Cyrus Imapd 3.0.8 on FreeBSD-12.0p3
We are obtaining these error messages on a regular basis:
Mar 25 04:20:00 inet17 kernel: pid 39793 (ipurge), uid 60: exited on
signal 11 (core dumped)
Mar 25 04:20:00 inet17 CYRUS/master[56223]: process type:EVENT
name:postmaster path:/usr/local/cyrus/sbin/ip
ulfon
--
Da: Patrick Boutilier
A: info-cyrus@lists.andrew.cmu.edu
Data: 8 dicembre 2017 14.24.25 CET
Oggetto: Re: squat core dump
On 12/08/2017 08:52 AM, Gabriele Bulfon wrote:
Hi, I'm getting a core dump while squattering folders, always on the
same folder:
08045e68 libcyrus.so.0.0.0`charset_e
On 12/08/2017 08:52 AM, Gabriele Bulfon wrote:
Hi, I'm getting a core dump while squattering folders, always on the
same folder:
08045e68 libcyrus.so.0.0.0`charset_extractitem+0x218(8052d40, 804604c,
a6, fe9607c9, 439b, 0)
08045ea8 libcyrus.so.0.0.0`charset_extractfile+0x33(8052d40, 80
Hi, I'm getting a core dump while squattering folders, always on the same
folder:
08045e68 libcyrus.so.0.0.0`charset_extractitem+0x218(8052d40, 804604c, a6,
fe9607c9, 439b, 0)
08045ea8 libcyrus.so.0.0.0`charset_extractfile+0x33(8052d40, 804604c, a6,
fe9607c9, 439b, 0)
08046008 libcyrus_im
PROTECTED]
Sent: Tuesday, September 09, 2008 3:12 AM
To: DEMBKOWSKI, Henryk (Henryk); Info Cyrus; Cyrus Devel
Cc: DEMBEK, Adam (Adam)
Subject: Re: Core dump from cyrusdb_skiplist.c
Yeah, you've got a corrupted skiplist file. There are a variety of
reasons why this could be the case, but most o
Yeah, you've got a corrupted skiplist file. There are a variety
of reasons why this could be the case, but most of all, the
skiplist library in 2.3.7 is pretty buggy. Well, no more buggy
than it had been for ages, but I got a LOT of fixes added since
then.
Probably the best skiplist library in c
Hi,
We are using cyrus-imapd-2.3.7 to store our messages.
And we got core from imap - file cyrusdb_skiplist.c
#0 myforeach (db=0x814b618, prefix=0xbfffb8c0 "user.6165602930", prefixlen=16,
goodp=0x8087dc0 ,
cb=0x80871d0 , rock=0xbfffb8b0, tid=0xbfffc91c) at
cyrusdb_skiplist.c:1019
1019
Hi,
After upgrade Cyrus-IMAP 2.2.12 32-bit up to Cyrus-IMAP 2.2.13 64-bit on
Solaris 9 sparc we have a problem under high load: imapd core dump with
signal 11:
2386cacheitem = CACHE_ITEM_NEXT(cacheitem); /* skip body */
(gdb) bt
#0 index_fetchreply (mailbox=0x1002046e0, msgno=43
Hi,
We are running Cyrus-IMAP 2.2.13 with Cyrus-SASL 2.1.22 and Berkeley DB
4.4.20 on Solaris 9. Periodically imapd core dump with signal 6:
(gdb) bt
#0 0x7cfa88ec in _libc_kill () from /usr/lib/64/libc.so.1
#1 0x7cf3e3c0 in abort () from /usr/lib/64/libc.so.1
#2
> We are running Cyrus-IMAP 2.2.13 with Cyrus-SASL 2.1.22 and Berkeley DB
> 4.4.20 on Solaris 9. Periodically imapd core dump with signal 6:
>
> (gdb) bt
> #0 0x7cda88ec in _libc_kill () from /usr/lib/64/libc.so.1
> #1 0x7f2120d4 in umem_do_abort () from /usr
We are running Cyrus-IMAP 2.2.13 with Cyrus-SASL 2.1.22 and Berkeley DB
4.4.20 on Solaris 9. Periodically imapd core dump with signal 6:
(gdb) bt
#0 0x7cda88ec in _libc_kill () from /usr/lib/64/libc.so.1
#1 0x7f2120d4 in umem_do_abort () from /usr/lib/64/libumem.so
#2
Patrick Welche wrote:
imapd dumps core when the user with the most email tries to "select inbox".
Has this already been fixed / look familiar? before I go down the system
limits route (as it is the ubiquitous signal 11)..
Core was generated by `imapd'.
Program terminated with signal 11, Segmenta
select "some other mailbox" doesn't cause a core dump.
deleting bursar.seen and bursar.sub seems to have fixed things?!
Patrick
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
.. of course I forgot to mention the version: Cyrus IMAP4 v2.2.2-BETA
Hence the question is this core dump real / fixed, or am I getting a
sigsegv because of something else eg system limits..
P
(gdb) bt
#0 0x08089fcc in find_node (db=0x812e680, key=0x812d4a0 "411b3b1e3fa295e4",
imapd dumps core when the user with the most email tries to "select inbox".
Has this already been fixed / look familiar? before I go down the system
limits route (as it is the ubiquitous signal 11)..
Core was generated by `imapd'.
Program terminated with signal 11, Segmentation fault.
...
#0 0x08
is freebsd included?
- Original Message -
Sent: Wednesday, January 08, 2003 3:47 PM
Subject: Re: squat core dump
>Date: Wed, 8 Jan 2003 18:22:06 -0200
>From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
>
>On Wed, 08 Jan 2003, Rob Siemborski wrote:
>
Date: Wed, 8 Jan 2003 18:22:06 -0200
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
On Wed, 08 Jan 2003, Rob Siemborski wrote:
> What bug number is this?
My bad, I did not add it to bugzilla, I just sent it to cyrus-bugs, a long
time ago. Hein Roehrig <[EMAIL PROTECTED]>
Its now Bug #1749.
-Rob
On Wed, 8 Jan 2003, Henrique de Moraes Holschuh wrote:
> On Wed, 08 Jan 2003, Rob Siemborski wrote:
> > What bug number is this?
>
> My bad, I did not add it to bugzilla, I just sent it to cyrus-bugs, a long
> time ago. Hein Roehrig <[EMAIL PROTECTED]> was the one who tr
On Wed, 08 Jan 2003, Rob Siemborski wrote:
> What bug number is this?
My bad, I did not add it to bugzilla, I just sent it to cyrus-bugs, a long
time ago. Hein Roehrig <[EMAIL PROTECTED]> was the one who tracked it down, btw.
URLs with data for the bug:
http://bugs.debian.org/cgi-bin/bugreport.c
On Wed, 08 Jan 2003, Ilya wrote:
> Today one of my users complained that the inbox doesnt show any messages.
> Upon investigation I saw that messages are still present, however there was an
> imapd.core file in that user's dir
> any suggestions?
> this is gdb trace:
> #0 0x8076036 in memconst (s=0
Today one of my users complained that the inbox doesnt show any messages.
Upon investigation I saw that messages are still present, however there was an
imapd.core file in that user's dir
any suggestions?
this is gdb trace:
#0 0x8076036 in memconst (s=0x2849cff2 ,
len=16, v=0) at squat.c:80
80
Don't like to reply to my own email but maybe someone is interested in
my findings. As other subscribers with similar problems I got no help
from the list but I found a solution for myself although I don't know
if this solution is permanent.
The procmail recipe below caused deliver to segfault.
As I described in my previous email a core dump is produced by deliver.
I now discovered, that every delivery causes a core dump.
Before I used a procmail script like
:0 w
| $DELIVERMAIL -a $LOGNAME -m user.$LOGNAME
($DELIVERMAIL is "/usr/local/bin/deliver -r $SENDER")
Since
[EMAIL PROTECTED] wrote:
>
> I think you've hit the bug I mailed in on 19th April (Subject: deliver -E
> (Solaris, 1.6.24 without DB). In part it read...
Thanks for your answer.
You're right, it seems to be the same bug
Does anyone know how to correct this ?
Is it corrected under 2.0.12 ?
Re
I think you've hit the bug I mailed in on 19th April (Subject: deliver -E
(Solaris, 1.6.24 without DB). In part it read...
---
On Solaris platforms which don't have DB available, deliver -E fails to
prune anything, ever. The problem starts in deliver.c, in the
_prune_actual_db routine. In it
Hello,
I'm running Cyrus IMAP4 v1.6.24 for
several months under solaris
and since yesterday
deliver -E 2 doesn't work any more
/usr/local/imap/imapd/bin/deliver -E 2
Bus Error - core dumped
I've tried to analyse why and made
a truss of /usr/local/imap/imapd/bin/deliver -E 2
I've got this:
HI
I am using cyrus 2.0.11 - Berkeley DB 3.2
Cyrus core dumps in several ways, here is the simplist.
Shutdown calls exit() in imapd.c as a result of processing
a LOGOUT imap4 command.
Any help would be appreciated.
Roger Massey
[Current thread is 1 (process 8651)]
(gdb) bt
#0 0x40009f00 in _
27 matches
Mail list logo
