similar to: zlib plugin aborts without zlib_save

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