dovecot-pigeonhole running external script ends with signal 11

Tobi tobster at brain-force.ch
Wed Jan 4 08:37:10 UTC 2017


Hi Aki

yes I built dovecot and pigeonhole rpms in the same rpmbuild. pigeonhole
rpm is based on 0.4.14
Do you think that the error might come from self building the rpms?

Regards

tobi

Am 04.01.2017 um 08:55 schrieb Aki Tuomi:
> On 04.01.2017 09:49, Tobi wrote:
>> Hi Stephan
>>
>> Am 03.01.2017 um 21:12 schrieb Stephan Bosch:
>>
>>> Since you're using LMTP, you could try to run the lmtp service from
>>> command line in GDB. In essence, this looks as follows (you will need to
>>> run this as the mail user, e.g. vmail, or you can run it as root):
>>>
>>> $ gdb --args /usr/lib/dovecot/lmtp 
>> I did so and it seems that libc.so.6 throws the error as I get the
>> following result (as root):
>>
>> [New process 14843]
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to process 14843]
>> 0x00007ffff7241b71 in __strlen_sse2 () from /lib64/libc.so.6
>>
>> bt full does not give me more than this
>>
>> #0  0x00007ffff7241b71 in __strlen_sse2 () from /lib64/libc.so.6
>> No symbol table info available.
>> Cannot access memory at address 0x7fffffffd848
>>
>> Then I installed debuginfo for glibc via debuginfo-install
>> glibc-2.17-157.el7_3.1.x86_64 and get
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to process 18099]
>> __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
>> 31		movdqu	(%rdi), %xmm1
>>
>> So this is an issue for glibc developpers? Just wonder why this error
>> does not occur if I call the script directly on cli or if I use
>> sieve-test program. It seems only to occur if the script called from dovecot
>>
>> To compare I tried gdb as well as user vmail and get more detailed
>> information
>>
>> [New process 20844]
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to process 20844]
>> 0x00007ffff7203694 in _IO_vfprintf_internal (s=s at entry=0x7fffffffd710,
>> format=<optimized out>,
>>     format at entry=0x555555764938 "chroot(%s) failed: Bad address",
>> ap=ap at entry=0x7fffffffd970) at vfprintf.c:1635
>> 1635		  process_string_arg (((struct printf_spec *) NULL));
>>
>> bt full does return much more in this case. I attached that output as
>> bt_full.txt to this mail (maybe it can be of help)
>>
>> Thanks for your help
>>
>> tobi
>>
> 
> Did you update both dovecot *and* pigeonhole when you last updated?
> 
> Aki
> 


More information about the dovecot mailing list