Hello Tom On 02.05.2017 11:19, Timo Sirainen wrote:> On 2 May 2017, at 10.41, Tom Sommer <mail at tomsommer.dk> wrote: >> >> (gdb) bt full >> #0 i_stream_seek (stream=0x21, v_offset=0) at istream.c:298 >> _stream = <value optimized out> >> #1 0x00007fe98391ff32 in i_stream_concat_read_next (stream=0x1efe6c0) at istream-concat.c:77 >> prev_input = 0x1ef1560 >> data = 0x0 >> data_size = <value optimized out> >> size = <value optimized out> >> #2 i_stream_concat_read (stream=0x1efe6c0) at istream-concat.c:175 > > This isn't very obvious.. There hasn't been any changes to istream-concat code in 2.2.29 and I can't really think of any other changes either that could be causing these crashes. Do these crashes happen to all mail deliveries or only some (any idea of percentage)? Maybe only for deliveries that have multiple recipients (in different backends)? We'll try to reproduce, but I'd think someone else would have already noticed/complained if it was that badly broken.. > > What's your doveconf -n? Also can you try running via valgrind to see what it logs before the crash? : > > service lmtp { > executable = /usr/bin/valgrind --vgdb=no -q /usr/libexec/dovecot/lmtp # or whatever the lmtp path really is > } >As this is not easily reproducible with a common lmtp proxying configuration, we would be interested in the doveconf -n output from all involved nodes (proxy, director, backend). Did you have a chance to try the valgrind wrapper adviced by Timo? br, Teemu
On 2017-05-18 09:36, Teemu Huovila wrote:> Hello Tom > > On 02.05.2017 11:19, Timo Sirainen wrote: >> On 2 May 2017, at 10.41, Tom Sommer <mail at tomsommer.dk> wrote: >>> >>> (gdb) bt full >>> #0 i_stream_seek (stream=0x21, v_offset=0) at istream.c:298 >>> _stream = <value optimized out> >>> #1 0x00007fe98391ff32 in i_stream_concat_read_next >>> (stream=0x1efe6c0) at istream-concat.c:77 >>> prev_input = 0x1ef1560 >>> data = 0x0 >>> data_size = <value optimized out> >>> size = <value optimized out> >>> #2 i_stream_concat_read (stream=0x1efe6c0) at istream-concat.c:175 >> >> This isn't very obvious.. There hasn't been any changes to >> istream-concat code in 2.2.29 and I can't really think of any other >> changes either that could be causing these crashes. Do these crashes >> happen to all mail deliveries or only some (any idea of percentage)? >> Maybe only for deliveries that have multiple recipients (in different >> backends)? We'll try to reproduce, but I'd think someone else would >> have already noticed/complained if it was that badly broken.. >> >> What's your doveconf -n? Also can you try running via valgrind to see >> what it logs before the crash? : >> >> service lmtp { >> executable = /usr/bin/valgrind --vgdb=no -q >> /usr/libexec/dovecot/lmtp # or whatever the lmtp path really is >> } >> > As this is not easily reproducible with a common lmtp proxying > configuration, we would be interested in the doveconf -n output from > all involved nodes (proxy, director, backend). > > Did you have a chance to try the valgrind wrapper adviced by Timo?Timo already fixed this? https://github.com/dovecot/core/commit/167dbb662c2ddedeb7b34383c18bdcf0537c0c84 --- Tom
On 2017-05-18 09:36, Teemu Huovila wrote:> Hello Tom > > On 02.05.2017 11:19, Timo Sirainen wrote: >> On 2 May 2017, at 10.41, Tom Sommer <mail at tomsommer.dk> wrote: >>> >>> (gdb) bt full >>> #0 i_stream_seek (stream=0x21, v_offset=0) at istream.c:298 >>> _stream = <value optimized out> >>> #1 0x00007fe98391ff32 in i_stream_concat_read_next >>> (stream=0x1efe6c0) at istream-concat.c:77 >>> prev_input = 0x1ef1560 >>> data = 0x0 >>> data_size = <value optimized out> >>> size = <value optimized out> >>> #2 i_stream_concat_read (stream=0x1efe6c0) at istream-concat.c:175 >> >> This isn't very obvious.. There hasn't been any changes to >> istream-concat code in 2.2.29 and I can't really think of any other >> changes either that could be causing these crashes. Do these crashes >> happen to all mail deliveries or only some (any idea of percentage)? >> Maybe only for deliveries that have multiple recipients (in different >> backends)? We'll try to reproduce, but I'd think someone else would >> have already noticed/complained if it was that badly broken.. >> >> What's your doveconf -n? Also can you try running via valgrind to see >> what it logs before the crash? : >> >> service lmtp { >> executable = /usr/bin/valgrind --vgdb=no -q >> /usr/libexec/dovecot/lmtp # or whatever the lmtp path really is >> } >> > As this is not easily reproducible with a common lmtp proxying > configuration, we would be interested in the doveconf -n output from > all involved nodes (proxy, director, backend). > > Did you have a chance to try the valgrind wrapper adviced by Timo?Timo already fixed this? I think? https://github.com/dovecot/core/commit/167dbb662c2ddedeb7b34383c18bdcf0537c0c84 --- Tom
On 18.05.2017 10:55, Tom Sommer wrote:> On 2017-05-18 09:36, Teemu Huovila wrote: >> Hello Tom >> >> On 02.05.2017 11:19, Timo Sirainen wrote: >>> On 2 May 2017, at 10.41, Tom Sommer <mail at tomsommer.dk> wrote: >>>> >>>> (gdb) bt full >>>> #0 i_stream_seek (stream=0x21, v_offset=0) at istream.c:298 >>>> _stream = <value optimized out> >>>> #1 0x00007fe98391ff32 in i_stream_concat_read_next (stream=0x1efe6c0) at istream-concat.c:77 >>>> prev_input = 0x1ef1560 >>>> data = 0x0 >>>> data_size = <value optimized out> >>>> size = <value optimized out> >>>> #2 i_stream_concat_read (stream=0x1efe6c0) at istream-concat.c:175 >>> >>> This isn't very obvious.. There hasn't been any changes to istream-concat code in 2.2.29 and I can't really think of any other changes either that could be causing these crashes. Do these crashes happen to all mail deliveries or only some (any idea of percentage)? Maybe only for deliveries that have multiple recipients (in different backends)? We'll try to reproduce, but I'd think someone else would have already noticed/complained if it was that badly broken.. >>> >>> What's your doveconf -n? Also can you try running via valgrind to see what it logs before the crash? : >>> >>> service lmtp { >>> executable = /usr/bin/valgrind --vgdb=no -q /usr/libexec/dovecot/lmtp # or whatever the lmtp path really is >>> } >>> >> As this is not easily reproducible with a common lmtp proxying >> configuration, we would be interested in the doveconf -n output from >> all involved nodes (proxy, director, backend). >> >> Did you have a chance to try the valgrind wrapper adviced by Timo? > > Timo already fixed this? I think? > > https://github.com/dovecot/core/commit/167dbb662c2ddedeb7b34383c18bdcf0537c0c84The commit in question fixes an asser failure. The issue you reported is an invalid memory access. The commit was not intended to fix your report. Has the crash stopped happening in your environment? br, Teemu> > --- > Tom