[asterisk-bugs] [Asterisk 0012987]: IMAP (apparently) causing system crash

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12987 
====================================================================== 
Reported By:                mthomasslo
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12987
Category:                   Applications/app_voicemail
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.20.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:             07-03-2008 14:47 CDT
Last Modified:              07-07-2008 12:44 CDT
====================================================================== 
Summary:                    IMAP (apparently) causing system crash
Description: 
Intermittently, and without any apparent pattern, the system will stop
responding.  For each failure (3 within the past 3 days) the message log
has two IMAP warnings immediately prior to the crash:

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
0000ad5d OK SEARCH completed

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
000cb22f OK [APPENDUID 1 287] APPEND completed

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
000cb420 OK [READ-WRITE]SELECT completed

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
000ad5d OK SEARCH completed

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
0000ee4c OK FETCH completed

WARNING[xxxxx] app_voicemail.c: IMAP Warning: Unexpected tagged response:
0000ad66 OK NOOP completed


 
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 07-07-08 12:44  
---------------------------------------------------------------------- 
I have fixed the compilation issues with IMAP voicemail in trunk.

Now to address the numbered points you have posted:
1. I'm not sure where or how this is happening. I grepped the source for
"vm-Inbox" and came up with no results. Do you know how this file is being
referenced?

2. Hmm, this makes sense, I suppose. Fixing this could be tricky. If users
were guaranteed to always access their voicemail via the phone, I would
suggest that the gain setting could be stored as an e-mail header and then
applied when the voicemail user actually listens to the message on the
phone. The problem is that since users may access the messages via an
e-mail client instead, we're forced to store the message with the volume
adjustment applied already. I suppose that we can somehow determine if the
gain has already been applied to that message so that we don't re-adjust
when the message is e-mailed subsequent times.

3. This is a known issue, http://bugs.digium.com/view.php?id=12764. I have been
working on it but have not
yet found the exact cause for this.

4. This is something I had not heard of before and off the top of my head,
I cannot imagine why it is happening.

The fatal "unlock when not locked" error is something that as far as I
know, we cannot help. Apparently a thread in the c-client is attempting to
unlock a mutex it did not previously lock. Apparently, the c-client aborts
when this happens, which means that it brings Asterisk down with it too. I
would suggest reporting this to the UW folks since it is something that is
their bug.

As for the four numbered points you made, I would suggest opening new bug
reports for issues 2 and 4 since they are legitimate but do not have to do
with the originally reported issue. Since issue 3 already has an open bug
report associated with it, you can follow it there. As for issue 1, I need
some more clarification before I'd suggest opening a bug report for it. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-07-08 12:44  putnopvut      Note Added: 0089844                          
======================================================================