Subject: [Imap-uw] Question about mailbox locks

From: Mike Schmidt <[email-masked]>
Date: Mon, 30 May 2005 14:32:33 -0400

Hello, all

I run c-client to an uw-imap server, and the mailboxes are in mbx 
format.  I have been getting mailbox lock error messages, and these are 
totally disastrous, because the call fatal().

Here is an extract from my log files:
5/29/2005 8:41:26 PM: MailStream: INBOX Checkmail
5/29/2005 8:41:26 PM: Debug: 00000021 NOOP
5/29/2005 8:41:27 PM: Debug: * 1 EXPUNGE
5/29/2005 8:41:27 PM: mm_expunged: 1
.....
5/29/2005 8:42:37 PM: MailStream: INBOX Checkmail
5/29/2005 8:42:37 PM: Fatal - Lock when already locked, 
mbx={mail.tt-express.com:143/imap/tls/user="....."}INBOX

The CheckMail always does a mail_ping() first, and then if that fails, a 
mail_open(). All callbacks to mm_log and mm_dlog are printed in the log 
file, an extraction of which you see above. It looks as though either 
the mail_ping() failed (no "Debug" traceback) and an extra mail_open was 
issued even though the mailbox was open,  or the mail_ping() itself 
caused the error. As you can see, it's been barely a minute since the 
last successful ping.

Is anyone able to enlighten me with respect to this error? It is 
particularly nasty since it calls fatal(), which kills everything. I 
can't have that happenning.
Why would it call fatal in the first place instead of just returning an 
error? How can I make sure that the sequence I follow never hits this 
error? I don't want to change any c-client code, so I can't to do 
anything direct about the call to fatal(). That would really be my last 
resort.

Thanks very much for any ideas you might have.

Mike

_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mike Schmidt <[email-masked]>
Date: Mon, 30 May 2005 14:47:12 -0400

Hello, again.

I just realized that I should have included the following code in my 
question (see below):

The code that actually performs the ping (and seems to return false/NIL) 
is the following:
bool ttx_Mail::Ping() {
    if (stream) {
        long lResult;
        lResult = mail_ping(stream);
        if (lResult && stream->mailbox) {
            return T;
        }
        else mm_dlog ("%No mailbox is open on this stream");
    }
    return NIL;
}

Mike Schmidt wrote:

> format.  I have been getting mailbox lock error messages, and these 
> are totally disastrous, because the call fatal().
>
> The CheckMail always does a mail_ping() first, and then if that fails, 
> a mail_open(). All callbacks to mm_log and mm_dlog are printed in the 
> log file, an extraction of which you see above. It looks as though 
> either the mail_ping() failed (no "Debug" traceback) and an extra 
> mail_open was issued even though the mailbox was open,  or the 
> mail_ping() itself caused the error. As you can see, it's been barely 
> a minute since the last successful ping.
>
> Why would it call fatal in the first place instead of just returning 
> an error? How can I make sure that the sequence I follow never hits 
> this error? I don't want to change any c-client code, so I can't to do 
> anything direct about the call to fatal(). That would really be my 
> last resort.
>

---

From: Mark Crispin <[email-masked]>
Date: Mon, 30 May 2005 21:29:44 -0700 (PDT)

The error message "Lock when already locked" has nothing to do with 
mailbox locks.  Instead, it is a bug in your program.  You attempted a 
recursive call to a mail_???() routine from an mm_???() callback routine. 
Doing so is forbidden; c-client's IMAP engine only permits a single 
command in progress on a stream at a time.

It calls fatal() because there is *no* way to recover from this other than 
your fixing the bug in your program that caused this to happen.  There is 
no possible error return when this happens.

Calling fatal() is a good thing.  It gives you a core dump, and by looking 
at the stack in the core dump it will show you the exact place that the 
recursive call was attempted.  You can do a similar thing on Windows with 
the Visual Studio debugger.

It needs to be emphasized that *no* mm_???() or other c-client callback 
routine can recursively call a mail_???() routine.  Callback routines can 
only record the data presented to them, and then return to c-client to 
finish the mail_???() function that caused the callback.

99 times out of 100, the buggy callback routine is an mm_exists(), 
mm_recent(), mm_expunged(), or mm_searched() routine.

For example, the following code is a blunder, and is an excellent example 
of the type of tempting mistake that novice c-client programmers often 
make (and sometimes even experts make this mistake too).  Thus, it's an 
instructive example to study and understand, albeit of what *NOT* to do:

void mm_exists (MAILSTREAM *stream,unsigned long msgno)
{
   /* This is an example of what NOT to do */
   ENVELOPE *env = mail_fetchenvelope (stream,msgno);
   if (env->from) {
     if (env->from->personal)
       printf ("New mail from %s\n",env->from->personal);
     else printf ("New mail from %s@%s\n",env->from->mailbox,
 		 env->from->host);
   }
}

When this routine is called, c-client will crash with the "Lock when 
already locked" message unless by the envelope for that message is already 
cached.

I hope that this helps explain what went wrong, and why.

On Mon, 30 May 2005, Mike Schmidt wrote:

> Hello, all
>
> I run c-client to an uw-imap server, and the mailboxes are in mbx format.  I 
> have been getting mailbox lock error messages, and these are totally 
> disastrous, because the call fatal().
>
> mail_open(). All callbacks to mm_log and mm_dlog are printed in the log file, 
> an extraction of which you see above. It looks as though either the 
> mail_ping() failed (no "Debug" traceback) and an extra mail_open was issued 
> even though the mailbox was open,  or the mail_ping() itself caused the 
> error. As you can see, it's been barely a minute since the last successful 
> ping.
>
> Is anyone able to enlighten me with respect to this error? It is particularly 
> nasty since it calls fatal(), which kills everything. I can't have that 
> happenning.
> error? How can I make sure that the sequence I follow never hits this error? 
> I don't want to change any c-client code, so I can't to do anything direct 
> about the call to fatal(). That would really be my last resort.
>

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw