[asterisk-bugs] [Asterisk 0014889]: Thread-specific vm_state tracking issue if a voicemail is left immediately after a restart.
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Apr 13 16:25:39 CDT 2009
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
======================================================================
More information about the asterisk-bugs
mailing list