Re: [Dovecot] Managesieve: Remote login fails
Stephan Bosch schreef:
Hello,
I've been trying to get managesieve to work for our LAN, but when I try to login from a remote host i always get the following line in the log file: dovecot: child 26014 (login) killed with signal 11
When i enable debuging, it just gives me that line, nothing more. I can only login from the localhost through telnet but not from a remote host. This is a segmentation fault (crash) and therefore definitely a bug in the ManageSieve service. But without more information I cannot fix find and fix this bug. You should try to obtain a core dump or a gdb
Brainkiller schreef: trace as explained at http://dovecot.org/bugreport.html . Debugging the login daemons can be a little more tricky. I usually attach gdb to the managesieve-login process that is handling my connection (using the gdb attach command). Be sure to compile dovecot with debugging symbols enabled (default Debian packages are stripped).
It is also interesting to know when exactly during the login process it crashes. If you login manually from a remote host (as explained in section 6 of http://wiki.dovecot.org/ManageSieve) you will be able to check where it crashes. If you do not use TLS, you can also sniff the traffic between client and server using ngrep to see where the login process dies.
Regards,
Hello again,
I tried to get a coredump with the infromation an the provided web-page. However i never got a dump. I used the packages provided by "deb http://xi.rename-it.nl/debian/ testing-auto main". I don't know if these contain the debugging symbols. So it seems i can't provide any further information.
Regard, Tom
On Nov 10, 2008, at 12:12 AM, Brainkiller - Tom wrote:
This is a segmentation fault (crash) and therefore definitely a
bug in the ManageSieve service. But without more information I
cannot fix find and fix this bug. You should try to obtain a core
dump or a gdb trace as explained at http://dovecot.org/bugreport.html . Debugging the login daemons can be a little more tricky. I
usually attach gdb to the managesieve-login process that is
handling my connection (using the gdb attach command). Be sure to
compile dovecot with debugging symbols enabled (default Debian
packages are stripped).It is also interesting to know when exactly during the login
process it crashes. If you login manually from a remote host (as
explained in section 6 of http://wiki.dovecot.org/ManageSieve) you
will be able to check where it crashes. If you do not use TLS, you
can also sniff the traffic between client and server using ngrep
to see where the login process dies.Regards,
Hello again,
I tried to get a coredump with the infromation an the provided web- page. However i never got a dump.
You can't get core dumps easily from login processes. The easiest way
to get a backtrace is:
- Set login_processes_count = 1
- Restart Dovecot and make sure you have only a single managesieve- login process.
- gdb -p
pidof managesieve-login - Give "c" command to gdb.
- Log in, causing the crash
- gdb should have now stopped, give it "bt full" command.
I used the packages provided by "deb http://xi.rename-it.nl/debian/
testing-auto main". I don't know if these contain the debugging
symbols. So it seems i can't provide any further information.
Even without debugging symbols you should be able to get some kind of
a backtrace.
Timo Sirainen schreef:
On Nov 10, 2008, at 12:12 AM, Brainkiller - Tom wrote:
This is a segmentation fault (crash) and therefore definitely a bug in the ManageSieve service. But without more information I cannot fix find and fix this bug. You should try to obtain a core dump or a gdb trace as explained at http://dovecot.org/bugreport.html . Debugging the login daemons can be a little more tricky. I usually attach gdb to the managesieve-login process that is handling my connection (using the gdb attach command). Be sure to compile dovecot with debugging symbols enabled (default Debian packages are stripped).
It is also interesting to know when exactly during the login process it crashes. If you login manually from a remote host (as explained in section 6 of http://wiki.dovecot.org/ManageSieve) you will be able to check where it crashes. If you do not use TLS, you can also sniff the traffic between client and server using ngrep to see where the login process dies.
Regards,
Hello again,
I tried to get a coredump with the infromation an the provided web-page. However i never got a dump.
You can't get core dumps easily from login processes. The easiest way to get a backtrace is:
- Set login_processes_count = 1
- Restart Dovecot and make sure you have only a single managesieve-login process.
- gdb -p
pidof managesieve-login- Give "c" command to gdb.
- Log in, causing the crash
- gdb should have now stopped, give it "bt full" command.
I used the packages provided by "deb http://xi.rename-it.nl/debian/ testing-auto main". I don't know if these contain the debugging symbols. So it seems i can't provide any further information.
Even without debugging symbols you should be able to get some kind of a backtrace. Thanks, I now have a full stacktrace however since i didn't have any debugging symbols so I think it won't be of any use. If the output below is off any use please let me know otherwise I'll try to get some time somewhere to install a version with debugging symbols.
GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". Attaching to process 27247 Reading symbols from /usr/lib/dovecot/managesieve-login...(no debugging symbols found)...done. Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.8 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /lib/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /lib/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 (no debugging symbols found) 0xffffe424 in __kernel_vsyscall () (gdb) c Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x08072fba in ?? () (gdb) bt full #0 0x08072fba in ?? () No symbol table info available. #1 0x0806c9b6 in ?? () No symbol table info available. #2 0x080989a0 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. (gdb)
Regards, Tom
Timo Sirainen wrote:
I tried to get a coredump with the infromation an the provided web-page. However i never got a dump.
You can't get core dumps easily from login processes. Oh d'oh, that is true. I always do the gdb trace trick. Maybe we should document this.
The easiest way to get a backtrace is:
- Set login_processes_count = 1
- Restart Dovecot and make sure you have only a single managesieve-login process.
- gdb -p
pidof managesieve-login- Give "c" command to gdb.
- Log in, causing the crash
- gdb should have now stopped, give it "bt full" command. You can also use netstat -plan to see which of the managesieve processes you are connected to (then there is no need to change your config). There should be one ESTABLISHED connection to a managesieve-login originating from your host. The number listed before process name (i.e. managesieve-login) is the pid needed for gdb.
I used the packages provided by "deb http://xi.rename-it.nl/debian/ testing-auto main". I don't know if these contain the debugging symbols. So it seems i can't provide any further information.
Even without debugging symbols you should be able to get some kind of a backtrace. If you build the package from source, you can easily force it to compile with debug symbols. Open the debian/rules file and deactivate (remove or comment) the line 'dh_strip -a' in the build-arch make rule (line 130). (There is probably a nicer way using environment variables, but I never cared to find out how).
Regards,
-- Stephan Bosch stephan@rename-it.nl
participants (3)
-
Brainkiller - Tom
-
Stephan Bosch
-
Timo Sirainen