[asterisk-bugs] [Asterisk 0010487]: IMAP integration with MS Exchange crashes Asterisk-1.4.10.1

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10487 
====================================================================== 
Reported By:                ewilhelmsen
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   10487
Category:                   Applications/app_voicemail
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.10.1  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-17-2007 12:59 CDT
Last Modified:              09-13-2007 16:21 CDT
====================================================================== 
Summary:                    IMAP integration with MS Exchange crashes
Asterisk-1.4.10.1
Description: 
When setting voicemail.conf to MS Exchange IMAP server I am able to record
a message and it will send to the users Exchange Inbox but when MS Exchange
sends an IMAP response to Asterisk it does not know the tagged response for
SEARCH and NOOP. After this Warning:

[Aug 17 10:59:19] WARNING[26191]: app_voicemail.c:8572 mm_log: IMAP
Warning: Unexpected tagged response: 0000003a OK SEARCH completed.
[Aug 17 10:59:19] WARNING[26204]: app_voicemail.c:8572 mm_log: IMAP
Warning: Unexpected tagged response: 0000003e OK NOOP
completed. 

Asterisk crashes and needs to be Ctrl-C to exit and restarted.
====================================================================== 

---------------------------------------------------------------------- 
 rayjay - 09-13-07 16:21  
---------------------------------------------------------------------- 
I noticed some fairly big lockups and then a couple of days ago I saw a big
lockup which forced me to kill -11 asterisk and restart the daemon as I had
live customers trying to make calls.  Backtrace in core shows something
different this time:

Program terminated with signal 11, Segmentation fault.
http://bugs.digium.com/view.php?id=0  __ast_pthread_mutex_unlock
(filename=0xb6f5a2e0 "chan_sip.c",
lineno=13498, func=0xb6f5f812 "handle_request_invite",
    mutex_name=0xb6f58228 "&p->refer->refer_call->owner->lock", t=0x78) at
/usr/src/asterisk/include/asterisk/lock.h:371
371             if (t->reentrancy && (t->thread[t->reentrancy-1] !=
pthread_self())) {
(gdb) bt
http://bugs.digium.com/view.php?id=0  __ast_pthread_mutex_unlock
(filename=0xb6f5a2e0 "chan_sip.c",
lineno=13498, func=0xb6f5f812 "handle_request_invite",
    mutex_name=0xb6f58228 "&p->refer->refer_call->owner->lock", t=0x78) at
/usr/src/asterisk/include/asterisk/lock.h:371
http://bugs.digium.com/view.php?id=1  0xb6f46e5b in handle_request_invite
(p=0xb65684f0, req=0xb6ee409c,
debug=1, seqno=1, sin=0xb6ee52c0, recount=0xb6ee52d0,
    e=0xb6ee42bf "sip:xxxx at xxx.xxx.xxx.xxx", nounlock=0xb6ee52d4) at
chan_sip.c:13498
http://bugs.digium.com/view.php?id=2  0xb6f4f262 in handle_request
(p=0xb65684f0, req=0xb6ee409c,
sin=0xb6ee52c0, recount=0xb6ee52d0, nounlock=0xb6ee52d4) at
chan_sip.c:14988
http://bugs.digium.com/view.php?id=3  0xb6f5149d in sipsock_read (id=0x81c35f8,
fd=22, events=1, ignore=0x0)
at chan_sip.c:15136
http://bugs.digium.com/view.php?id=4  0x080c6cf0 in ast_io_wait (ioc=0x824def0,
howlong=1) at io.c:279
http://bugs.digium.com/view.php?id=5  0xb6f2c75e in do_monitor (data=0x0) at
chan_sip.c:15342
http://bugs.digium.com/view.php?id=6  0x08132651 in dummy_start (data=0x821c6b8)
at utils.c:775
http://bugs.digium.com/view.php?id=7  0xb7fc80bd in start_thread () from
/lib/tls/libpthread.so.0
http://bugs.digium.com/view.php?id=8  0xb7df29ee in clone () from
/lib/tls/libc.so.6

Again, I have protected the user's privacy involved.  I have now set my
checkmwi to 3600000 (1000 hours), so I am no longer getting any check MWI
polling against the mail server and users must SUBSCRIBE for MWI events
now.  Since I effectively disabled checkmwi I have noticed the platform is
much more responsive and stable - I have had no locks/hangs occur for over
2 days and the load on the IMAP server has gone from 1.5 to 0.0, so I think
that the constant polling of mailboxes by the checkmwi is causing most of
the instability.  It doesn't explain the bug away - but disabling checkmwi
does seem to have a big impact on how frequently the system hangs or locks
up because of a massive reduction in IMAP traffic?  I think the other
problem is that checkmwi seems to poll all the mailboxes in one big hit
rather than spread over a larger timeframe.

For stability reasons I'm going to have to leave checkmwi off for now, so
I'm not sure if I'll get any more crashes/core dumps now... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-13-07 16:21  rayjay         Note Added: 0070504                          
======================================================================