thr3ads.net - dovecot - dovecot-pigeonhole running external script ends with signal 11 [Jan 2017]

If this information is useful, please help other people find it:
Share via:

Tobi

2017-Jan-04 07:49 UTC

dovecot-pigeonhole running external script ends with signal 11

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

-------------- next part --------------
#0  0x00007ffff7203694 in _IO_vfprintf_internal (s=s at entry=0x7fffffffd710,
format=<optimized out>,
    format at entry=0x555555764938 <Address 0x555555764938 out of bounds>,
ap=ap at entry=0x7fffffffd970) at vfprintf.c:1635
        len = <optimized out>
        string_malloced = <optimized out>
        step0_jumps = <error reading variable step0_jumps (Cannot access
memory at address 0x7ffff7331d00)>
        space = <error reading variable space (Cannot access memory at
address 0x7fffffffd1c0)>
        is_short = <error reading variable is_short (Cannot access memory at
address 0x7fffffffd1a0)>
        use_outdigits = <error reading variable use_outdigits (Cannot access
memory at address 0x7fffffffd198)>
        step1_jumps = <error reading variable step1_jumps (Cannot access
memory at address 0x7ffff7331c80)>
        group = <error reading variable group (Cannot access memory at
address 0x7fffffffd190)>
        prec = <error reading variable prec (Cannot access memory at address
0x7fffffffd1d8)>
        step2_jumps = <error reading variable step2_jumps (Cannot access
memory at address 0x7ffff7331c00)>
        string = <optimized out>
        left = <error reading variable left (Cannot access memory at address
0x7fffffffd1c8)>
        is_long_double = <error reading variable is_long_double (Cannot
access memory at address 0x7fffffffd19c)>
        width = <error reading variable width (Cannot access memory at
address 0x7fffffffd1e0)>
        step3a_jumps = <error reading variable step3a_jumps (Cannot access
memory at address 0x7ffff7331b80)>
        alt = <error reading variable alt (Cannot access memory at address
0x7fffffffd1e8)>
        showsign = <error reading variable showsign (Cannot access memory at
address 0x7fffffffd1b8)>
        is_long = <error reading variable is_long (Cannot access memory at
address 0x7fffffffd1d0)>
        is_char = <error reading variable is_char (Cannot access memory at
address 0x7fffffffd188)>
        pad = <error reading variable pad (Cannot access memory at address
0x7fffffffd1b0)>
        step3b_jumps = <error reading variable step3b_jumps (Cannot access
memory at address 0x7ffff7331a80)>
        step4_jumps = <error reading variable step4_jumps (Cannot access
memory at address 0x7ffff7331b00)>
        is_negative = <optimized out>
        number = <optimized out>
        base = <optimized out>
        the_arg = <error reading variable the_arg (Cannot access memory at
address 0x7fffffffd270)>
        spec = <error reading variable spec (Cannot access memory at address
0x7fffffffd200)>
        _buffer = <error reading variable _buffer (Cannot access memory at
address 0x7fffffffd2c0)>
        _avail = <optimized out>
        thousands_sep = <error reading variable thousands_sep (Cannot access
memory at address 0x7fffffffd1f0)>
        grouping = <error reading variable grouping (Cannot access memory at
address 0x7fffffffd1f8)>
        done = <error reading variable done (Cannot access memory at address
0x7fffffffd238)>
        f = <error reading variable f (Cannot access memory at address
0x7fffffffd240)>
        lead_str_end = <optimized out>
        end_of_spec = <optimized out>
        work_buffer = <error reading variable work_buffer (Cannot access
memory at address 0x7fffffffd2e0)>
        workstart = 0x0
        workend = <optimized out>
        ap_save = <error reading variable ap_save (Cannot access memory at
address 0x7fffffffd2a0)>
        nspecs_done = <error reading variable nspecs_done (Cannot access
memory at address 0x7fffffffd208)>
        save_errno = <optimized out>
        readonly_format = <error reading variable readonly_format (Cannot
access memory at address 0x7fffffffd1ec)>
        args_malloced = <error reading variable args_malloced (Cannot access
memory at address 0x7fffffffd220)>
        specs = <optimized out>
        specs_malloced = <error reading variable specs_malloced (Cannot
access memory at address 0x7fffffffd20f)>
        jump_table = <error reading variable jump_table (Cannot access memory
at address 0x7ffff7331d80)>
#1  0x00007ffff72c78d5 in ___vsnprintf_chk (s=0x555555764855 <Address
0x555555764855 out of bounds>,
    s at entry=<error reading variable: Cannot access memory at address
0x7fffffffd878>, maxlen=<optimized out>, flags=1, slen=<optimized
out>,
    format=0x555555764938 <Address 0x555555764938 out of bounds>,
args=0x7fffffffd970) at vsnprintf_chk.c:63
        sf = <error reading variable sf (Cannot access memory at address
0x7fffffffd710)>
        ret = <optimized out>

Aki Tuomi

2017-Jan-04 07:55 UTC

head link

dovecot-pigeonhole running external script ends with signal 11

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

Tobi

2017-Jan-04 08:37 UTC

head link

dovecot-pigeonhole running external script ends with signal 11

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
>

Steffen Kaiser

2017-Jan-06 07:56 UTC

head link

dovecot-pigeonhole running external script ends with signal 11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 4 Jan 2017, Tobi wrote:
> [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));
Does your script tries to chroot?
Do you have LMTP or Dovecot configured to chroot?
As Stephan asked, can you determine with process is spawned here?

The format string "chroot(%s) failed: Bad address" may stem from a
Dovecot
library.

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWG9Nxnz1H7kL/d9rAQJIrgf/Y6NvtcCa0HkOHogOJwC42a5NSpA5nqlP
sdANI8onYt/JReJA9PzeIKXgCps92xj0d85LNAIVcS4HjKcnBJZLSuWCVg8ppyjy
NQbW499DsPtW/sw4bjs4P/yUR5eLw8ERV5EOABwemTBQz03EuBVa4bm6vkses+sN
X+C9WJ54bBtjH6fPljpTagwfijNgAnPbkr/EuthMOKzx5IS02Nr3ec0hgDdFGHPu
4slRViTuYSr1dx0MmsqdiEE6wDdZLagLuc6kpVWa5M04L7wrQIri4b6AECf5sFOZ
YQaosywbBTZKGYMXGHwX09A3wa8Uei1WgXkRNh6NyVbdy+Ubp5Dahw==ntGy
-----END PGP SIGNATURE-----

Seemingly Similar Threads

Search for more possibly parallel threads

dovecot - Jan 2017 - dovecot-pigeonhole running external script ends with signal 11

dovecot-pigeonhole running external script ends with signal 11

dovecot-pigeonhole running external script ends with signal 11

dovecot-pigeonhole running external script ends with signal 11

dovecot-pigeonhole running external script ends with signal 11

Seemingly Similar Threads