[asterisk-bugs] [Asterisk 0014889]: Thread-specific vm_state tracking issue if a voicemail is left immediately after a restart.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14889 
====================================================================== 
Reported By:                jaroth
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14889
Category:                   Applications/app_voicemail/IMAP
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 188038 
Request Review:              
====================================================================== 
Date Submitted:             2009-04-13 15:16 CDT
Last Modified:              2009-04-13 16:25 CDT
====================================================================== 
Summary:                    Thread-specific vm_state tracking issue if a
voicemail is left immediately after a restart.
Description: 

When calling vmexec to leave a voicemail, pthread_getspecific() is called
before pthread_setspecific() is called, thereby returning an undefined
vm_state structure.  The following functions (get_vm_state_by_imapuser,
get_vm_state_by_mailbox, create_vm_state_from_user) could call
pthread_getspecific during vmexec.

The specific behavior is that if you leave a message for a mailbox that
has not been accessed since a restart, pthread_getspecific will not return
a valid vm_state and therefor message counts will be incorrect (all zeros).
====================================================================== 

---------------------------------------------------------------------- 
 (0103182) msirota (reporter) - 2009-04-13 16:25
 http://bugs.digium.com/view.php?id=14889#c103182 
---------------------------------------------------------------------- 
More detail about this bug (sorry about the verbosity, I hope it's
helpful):

Again, the case in question is when a new message is left for an IMAP
mailbox that has not been read since the last restart, and the goal is to
deliver accurate message counts to externnotify.

run_externnotify() is called by notify_new_message() from
leave_voicemail().

In the case where a message is left for a mailbox that has not yet been
read since Asterisk restarted, leave_voicemail() creates a new vm_state
using create_vm_state_from_user().  This vm_state currently has no message
counts (all zeros).  We would like to set the message counts in this
vm_state using messagecount().

messagecount() first searches for an interactive vm_state.  There
shouldn't be one for this mailbox, because the first thing that happened
was to leave a message, so no interactive vm_state should exist.  However,
messagecount() finds one anyway.

It would appear that it finds this phantom vm_state by calling
get_vm_state_by_imapuser() or get_vm_state_by_mailbox() with the
Interactive flag set to True.  Because Interactive is true, these functions
call pthread_getspecific(), which always returns a vm_state.

However, pthread_setspecific() is only called for interactive sessions. 
There hasn't been an interactive session for this mailbox yet, so
pthread_getspecific() is returning a phantom vm_state.

Two possible approaches to fix this:
(1) call pthread_setspecific() even for non-interactive sessions
(2) avoid calling pthread_getspecific() for non-interactive sessions.

I can't recommend a specific solution because I don't understand exactly
problem this pthread_setspecific()/pthread_getspecific() is there to
solve.

Either way, our goal is to have messagecount() find the non-interactive
vm_state created by leave_voicemail(), rather than finding a phantom
interactive vm_state that doesn't really exist.  Thanks. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-13 16:25 msirota        Note Added: 0103182                          
======================================================================