Displaying 20 results from an estimated 2000 matches similar to: "zlib plugin aborts without zlib_save"
2017 Dec 24
3
zlib plugin producing errors on 2.3.0
Hello,
I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs
are producing these errors every so often, but AFAICT the messages
themselves aren't getting corrupted.
Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion failed: (zstream->ostream.finished || zstream->ostream.ostream.stream_errno != 0)
Fatal: master: service(imap): child 80128 killed with
2018 Jan 06
2
zlib plugin producing errors on 2.3.0
On 5 Jan 2018, at 18.33, Carsten Uppenbrink <info at uppenbrink.net> wrote:
>
> On 24.12.2017 15:58, Adam Weinberger wrote:
>> Hello,
>> I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs
>> are producing these errors every so often, but AFAICT the messages
>> themselves aren't getting corrupted.
>> Panic: file ostream-zlib.c: line
2018 Jan 05
0
zlib plugin producing errors on 2.3.0
On 24.12.2017 15:58, Adam Weinberger wrote:
> Hello,
>
> I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs
> are producing these errors every so often, but AFAICT the messages
> themselves aren't getting corrupted.
>
> Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion
> failed: (zstream->ostream.finished ||
>
2018 Jan 09
0
zlib plugin producing errors on 2.3.0
On 06.01.2018 20:54, Timo Sirainen wrote:
> On 5 Jan 2018, at 18.33, Carsten Uppenbrink <info at uppenbrink.net> wrote:
>> On 24.12.2017 15:58, Adam Weinberger wrote:
>>> Hello,
>>> I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs
>>> are producing these errors every so often, but AFAICT the messages
>>> themselves aren't
2018 Oct 02
2
2.3.3: Panic: file ostream-zlib.c: line 37 (o_stream_zlib_close): assertion failed
I see this in my logs after 2.3.3:
using zlib plugin, ofc.
Oct 02 10:01:39 imap(user at example.com)<50643></2k4Sjp3vMqC496W>: Panic:
file ostream-zlib.c: line 37 (o_stream_zlib_close): assertion failed:
(zstream->ostream.finished || zstream->ostream.ostream.stream_errno != 0
|| zstream->ostream.error_handling_disabled)
Oct 02 10:01:39 imap(user at
2018 Jan 18
1
Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion failed:
Hi,
after updating Dovecot to version 2.3 I get a lot of core-dumps like:
> Jan 18 10:08:20 mail dovecot: imap(bob at tutech.de)<18200><CIPhNwljJcdYS/hg>: Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion failed: (zstream->ostream.finished ||
> zstream->ostream.ostream.stream_errno != 0)
> Jan 18 10:08:20 mail dovecot: imap(bob at
2013 Nov 05
0
infinite loop (causing crash) whilst closing connection
Hi Timo,
As a follow-up to my earlier email, I've managed to get a few backtraces
now.
#305439 o_stream_close (stream=0x1680c10) at ostream.c:85
#305440 0x00007ff222f70f3c in o_stream_zlib_send_outbuf (zstream=0x1680b80)
at ostream-zlib.c:97
#305441 0x00007ff222f70fef in o_stream_zlib_send_flush (zstream=0x1680b80)
at ostream-zlib.c:182
#305442 0x00007ff222f711cb in o_stream_zlib_flush
2010 Mar 11
1
Plugin like zlib
Hi everyone.
I rebuild a plugin, based on zlib plugin.
The changes between this plugin and zlib, is the zlib stuffs is replaced by
open, read, lseek, close.
With "plain-text" files, its works ok.
So, my file is encrypt, and the result from decrypt file is different from
fread.
Like zlib, i read from fread the size variable, but the value added in
seek_offset and pos is the result from
2013 Nov 12
2
dovecot-2.2.7: Fatal: master: service(imap): child 49545 killed with signal 11 (core dumped)
Hi!
After upgrade I'm noticing many coredummps, below is backtrace:
$ echo "bt"|gdb ....
#0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222
222 if (o_stream_zlib_send_flush(zstream) < 0)
(gdb) #0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222
#1 0x00007a695e8f09cd in o_stream_flush
(stream=stream at entry=0xc8be5b276d0) at
2018 Jan 20
0
PDFs getting mangled
> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote:
>
>
>> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
>>
>>
>>
>> On 19.01.2018 04:35, Adam Weinberger wrote:
>>> Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled.
>>> It seems to be happening when I use
2018 Jan 20
2
PDFs getting mangled
> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
>
>
>
> On 19.01.2018 04:35, Adam Weinberger wrote:
>> Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled.
>> It seems to be happening when I use vnd.dovecot.filter. When I comment
>> out the block, things come through fine.
>>
>> My filter block looks like
2018 Jan 22
0
PDFs getting mangled
Op 1/21/2018 om 4:34 PM schreef Stephan Bosch:
> Op 1/20/2018 om 11:01 PM schreef Adam Weinberger:
>>> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote:
>>>
>>>
>>>> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
>>>>
>>>>
>>>>
>>>> On 19.01.2018 04:35,
2018 Jan 21
2
PDFs getting mangled
Op 1/20/2018 om 11:01 PM schreef Adam Weinberger:
>> On 20 Jan, 2018, at 10:05, Adam Weinberger <adamw at adamw.org> wrote:
>>
>>
>>> On 19 Jan, 2018, at 4:39, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
>>>
>>>
>>>
>>> On 19.01.2018 04:35, Adam Weinberger wrote:
>>>> Since upgrading to 2.3.0 / 0.5.0.1, incoming
2017 Dec 19
2
Pigeonhole implicit keep gets unfiltered message
I'm getting a behaviour with pigeonhole that I wasn't expecting. Am I
misunderstanding the design?
I run my messages through a vnd.dovecot.filter. It's essentially this:
filter "spam_filter";
if spamheaders {
fileinto "spam";
stop;
}
Mail stored in the spam folder is the filtered version, but the
implicit-keep message is the original, unfiltered
2017 Dec 22
2
Pigeonhole implicit keep gets unfiltered message
> On 21 Dec, 2017, at 14:37, Stephan Bosch <stephan at rename-it.nl> wrote:
>
> Op 12/19/2017 om 8:41 AM schreef Adam Weinberger:
>> I'm getting a behaviour with pigeonhole that I wasn't expecting. Am I
>> misunderstanding the design?
>>
>> I run my messages through a vnd.dovecot.filter. It's essentially this:
>>
>> filter
2018 Jan 19
0
PDFs getting mangled
On 19.01.2018 04:35, Adam Weinberger wrote:
> Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled.
> It seems to be happening when I use vnd.dovecot.filter. When I comment
> out the block, things come through fine.
>
> My filter block looks like this:
> require "vnd.dovecot.filter";
> filter "bogofilter_filter";
>
>
2018 Jan 19
3
PDFs getting mangled
Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled.
It seems to be happening when I use vnd.dovecot.filter. When I comment
out the block, things come through fine.
My filter block looks like this:
require "vnd.dovecot.filter";
filter "bogofilter_filter";
if header :contains "X-Bogosity" [
"Spam,
2016 Jul 01
2
kqueue crash on FreeBSD with 2.2.25
Hi,
2.2.25 crashes on FreeBSD with a kqueue-related message. I see references to something similar (http://www.dovecot.org/list/dovecot/2012-February.txt) from a couple years ago.
I get:
Jul 1 10:07:27 imap dovecot: master: Panic: kevent(EV_ADD, READ, 54) failed: Bad file descriptor
It's not dumping core, and I get the message even with "protocols ="
Downgrading back to 2.2.24
2016 Jul 04
3
kqueue crash on FreeBSD with 2.2.25
On 16-07-03 03:30:36, Timo Sirainen wrote:
> On 02 Jul 2016, at 03:30, Adam Weinberger <adamw at adamw.org> wrote:
> >
> >>> Jul 1 10:07:27 imap dovecot: master: Panic: kevent(EV_ADD, READ, 54) failed: Bad file descriptor
> >>>
> >>> It's not dumping core, and I get the message even with "protocols ="
> >>>
>
2010 Aug 31
0
istream_read like zlib, but without zlib
Hy Timo !
I Made some modification in stream_read in zlib. I remove all zlib part,
because i don't need this, but i need to read a istream to change it.
Well, i create a size_t called supersize, with is a substitute for
stream->zs.avail_in.
The trouble is, my debug file have a lot of "READ Plugin\n", and i think
it's because my read becomes a loop, i think it's because