[asterisk-bugs] [Asterisk 0013124]: [patch] Search channel by name prefix fails if a previous channel was defined in ast_channel_find_locked.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13124 
====================================================================== 
Reported By:                ramonpeek
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13124
Category:                   Core/Channels
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21 
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-21-2008 10:03 CDT
Last Modified:              07-23-2008 13:46 CDT
====================================================================== 
Summary:                    [patch] Search channel by name prefix fails if a
previous channel was defined in ast_channel_find_locked.
Description: 
Search channel by name prefix fails if a previous channel was defined in
ast_channel_find_locked.

The function always return the previous value, because the previous
channel value was constantly restored.
This caused failures in applications like Chanspy if searching for the
next active channel with a certain prefix was used.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 07-23-08 13:46  
---------------------------------------------------------------------- 
It doesn't make sense to me what the problem actually is in
channel_find_locked. The current code looks right to me. I think that more
likely than not, there are places where this function is being used
incorrectly. In other words, it is the responsibility of the caller of
channel_find_locked (or one of the other entry points into the function) to
be sure that the prev input pointer is updated between calls.

You mentioned chanspy as an example where the function appeared broken.
Could you outline how it's broken. I admit that in the case that a
Zap/pseudo channel is found, it appears that the code does not properly
update the "last" channel pointer as it should. I will get this fix merged. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-23-08 13:46  putnopvut      Note Added: 0090624                          
======================================================================