Re: [PERDITION-USERS] Exiting on signal 11

On Mon, Apr 04, 2011 at 02:52:59PM -0400, YANG ChengFu wrote: Hi, thanks for the detailed bug report and sorry for taking so long to look into this. I have tried to replicate your setup - perdition 1.19~rc4-2 on squeeze - but unfortunately I am unable to reproduce the problem that you are seeing on both x86_32 (i386) and x86_64 (amd64). I do have a few ideas for you to try, hopefully one of them can bring us closer to resolving this problem. 1) There is a manage-sieve authentication bug resolved in the tip of mercurial that was present in 1.19~rc4-2. I do not think this is the bug you are seeing, but its probably worth checking out the mercurial tree and verifying that the problem you are seeing still manifests with that code. hg clone http://hg.vergenet.net/perdition/perdition/rev/6544c58ec144 cd 6544c58ec144/ apt-get build-dep perdition ./configure make 2) I think that it would be worth trying to get perdition to dump a core file and seeing if that sheds any light on the problem. Unfortuantely getting perdition to produce a code file is a somewhat more difficult than it ought to me - as I discovered while looking into things this morning. 0) Check to see if your problem manifests when perdition is running in inetd mode (its easier to get perdition to produce core files in that mode). ./perdition/perdition -P managesieve -i -f /etc/perdition/perdition.managesieve.conf You should see something like this: "IMPLEMENTATION" "perdition" "SIEVE" "comparator-i;octet comparator-i;ascii-casemap fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date" "SASL" "PLAIN" "NOTIFY" "mailto" "VERSION" "1.19-rc4" OK "perdition ready on joe 00026eea" Then in the terminal type (or paste :-) AUTHENTICATE "PLAIN" "AGNoZW5nZnUueWFuZ0BnYW1lbG9mdC5jb20AUjNsMGFkZWQ4" Then perdition should exit (if the bug is manifesting) i) Make sure ulimit isn't inhibiting the creation of core files ulimit -c unlimited ii) Apply the patch below so that perdition doesn't prevent the creation of core files iii) Build with -g in CFLAGS to include debugging symbols in the perdition binary make clean CFLAGS="-g" ./configure make iv) Run perdition in inetd mode ./perdition/perdition -P managesieve -i -f /etc/perdition/perdition.managesieve.conf And paste the following in the console AUTHENTICATE "PLAIN" "AGNoZW5nZnUueWFuZ0BnYW1lbG9mdC5jb20AUjNsMGFkZWQ4" And if the bug is manifesting you should get Segmentation fault (core dumped) The "(core dumped)" bit is critical, else there is no core file to work with. If there is a core file, you should be able to use gdb to get an idea of what went wrong. Or at least, approximately where things went wrong. gdb ./perdition/perdition core bt diff -r 6544c58ec144 perdition/perdition.c --- a/perdition/perdition.c Tue Dec 21 07:44:19 2010 +0900 +++ b/perdition/perdition.c Thu May 12 09:41:57 2011 +0900 @@ -410,7 +410,6 @@ signal(SIGBUS, perdition_exit_cleanly); signal(SIGFPE, perdition_exit_cleanly); signal(SIGUSR1, vanessa_socket_handler_noop); - signal(SIGSEGV, perdition_exit_cleanly); signal(SIGUSR2, vanessa_socket_handler_noop); signal(SIGPIPE, SIG_IGN); signal(SIGALRM, perdition_exit_cleanly); @@ -521,7 +520,7 @@ /* Close file descriptors and detach process from shell as necessary */ if (opt.inetd_mode || opt.no_daemon || fh != NULL) - vanessa_socket_daemon_inetd_process(); + ;//vanessa_socket_daemon_inetd_process(); else { vanessa_socket_daemon_process(); if (vanessa_logger_reopen(vanessa_logger_get()) < 0) {