Re: Exiting on signal 11

On Mon, Apr 04, 2011 at 02:52:59PM -0400, YANG ChengFu wrote:
> Hello,
> 
> I have perdition installation with imap and managesieve service, imap
> works very well, but managesieve never works.
> 
> my setup:
> Debian Squeeze 6.01
> perdition 1.19~rc4-2
> 
> Each time I tried to login from perdition server to real
> server(managesieve works on it, it is dovecot).
> 
> $ telnet email.tst.gameloft.org 2000
> Trying 10.137.0.45...
> Connected to email.tst.gameloft.org.
> Escape character is '^]'.
> "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"
> OK "predition ready on email.tst.gameloft.org 0002a618"
> AUTHENTICATE "PLAIN" "AGNoZW5nZnUueWFuZ0BnYW1lbG9mdC5jb20AUjNsMGFkZWQ4"
> Connection closed by foreign host.
> 
> I got the following error message. I can find perdition.managesieve
> forward my authentication information to real server from tcpdump

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) {
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users