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 [EMAIL PROTECTED]",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().
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 protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
-- 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 protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
