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/lmtpI 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
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
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
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-----
Maybe Matching Threads
- 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