lmtp segfault after upgrade

[Tom Sommer]

---
Tom

On 2017-05-18 10:05, Teemu Huovila wrote:
> 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/167dbb662c2ddedeb7b34383c18bdcf0537c0c84
> The 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?

Well, I downgraded to 2.2.26 and haven't looked at 2.2.29 since. So I 
guess it's not fixed.

I'll give it another look with valgrind.

// Tom