service imap pid nnnn in BUSY state: terminated abnormally

[Aidan Evans]

On Fri, 29 May 2009 at 14:47 Aidan Evans wrote to info-cyrus at lists.andrew.c...

>  I am attempting to upgrade a Cyrus Murder from 2.3.12p2 to 2.3.14.  The
> mupdate and backend servers are happy at 2.3.14, but on the frontends while
> I can login successfully, attempting to select a folder fails with messages
> like
>
> May 29 12:13:59 kil-imap-13 master[15558]: process 15584 exited, signaled to 
> death by 11
> May 29 12:13:59 kil-imap-13 master[15558]: service imap pid 15584 in BUSY 
> state: terminated abnormally
>
> This is on Red Hat Linux 5 (2.6.18-128.1.6.el5PAE kernel).

   It appears this is ultimately a problem with the xstrdup function in
xmalloc.c, or with its usage.  The imap service failure occurs in backend.c
in the following code starting about line 424 in the 2.3.14 source

     /* now need to authenticate to backend server,
        unless we're doing LMTP/CSYNC on a UNIX socket (deliver/sync_client) */
     if ((server[0] != '/') ||
         (strcmp(prot->sasl_service, "lmtp") &&
          strcmp(prot->sasl_service, "csync"))) {
         char *mlist = xstrdup(mechlist); /* backend_auth is destructive */

         if ((r = backend_authenticate(ret, prot, &mlist, userid,
                                       cb, auth_status))) {

In the call to xstrdup, the value of mechlist happens to be NULL.  xstrdup 
is

char *xstrdup(const char* str)
{
     char *p = xmalloc(strlen(str)+1);
     strcpy(p, str);
     return p;
}

and the strlen(str) when str is NULL produces a segmentation fault.

   If I change

         char *mlist = xstrdup(mechlist); /* backend_auth is destructive */
to
         char *mlist = mechlist ? xstrdup(mechlist) : NULL; /* backend_auth is destructive */

a "SELECT folder" no longer crashes.

   This leads me to conclude thqt either one must ensure that xstrdup is 
never called with a NULL string pointer, or maybe xstrdup should check for 
this and return NULL in that case (this would be relieve callers from having 
to check).

   Of course the bigger question is why I am seeing this problem and 
apparently no one else is.

Aidan Evans   | Networks & Systems
(902)494-3332 | Dalhousie University, Halifax, N.S., Canada