Summary:ASTERISK-12601: pattern match for a hints always gives state:idle for all extensions
Reporter:pj (pj)Labels:
Date Opened:2008-08-16 15:43:07Date Closed:2008-12-12 10:24:42.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 20080906__bug13327.diff.txt
( 1) locks.txt
( 2) locks2.txt
Description:I'm using this ael syntax for pattern match for hints
       hint(SIP/${EXTEN}) _ZXX => NoOP;
when subscribe to extensions using this pattern match, it gives always "idle" state for all subscribed extensions, regardless of actual state of line, it shows always "idle" for unregistered, or even not existent peers!

pattern match for hints feature was added into trunk in rev. 109970


[ Context 'linestates' created by 'pbx_ael' ]
 '108' =>          hint: SIP/${EXTEN}                            [pbx_ael]
 '322' =>          hint: SIP/${EXTEN}                            [pbx_ael]
 '324' =>          hint: SIP/${EXTEN}                            [pbx_ael]
 '_ZXX' =>         hint: SIP/${EXTEN}                            [pbx_ael]
                   1. NoOP()                                     [pbx_ael]

   -= Registered Asterisk Dial Plan Hints =-
                   108@linestates          : SIP/${EXTEN}          State:Idle            Watchers  1
                   324@linestates          : SIP/${EXTEN}          State:Idle            Watchers  2
                   322@linestates          : SIP/${EXTEN}          State:Idle            Watchers  1
                  _ZXX@linestates          : SIP/${EXTEN}          State:Idle            Watchers  0
Comments:By: pj (pj) 2008-08-16 16:06:15

to work correctly, pattern match for hints feature should automatically replace  "SIP/${EXTEN}", from example above, to extension number which is actually subscribed, eg.
108@linestates : SIP/${EXTEN} State:Idle Watchers 1
108@linestates : SIP/108 State:Idle Watchers 1

By: Tilghman Lesher (tilghman) 2008-09-05 17:09:42

Actually, no, it's designed specifically not to replace it.  The reason is to allow you to do more complex lookups, such as via func_odbc to get the channel name.  If we replaced it, then the channel name could never change afterwards.

By: pj (pj) 2008-09-05 20:46:59

Corydon76, I don't understand you, do you disagree, that this is bug? One thing, that I expecting from feature "pattern match as a hint" is, that I will use single line in dialplan like "hint(SIP/${EXTEN}) _ZXX => NoOP;" to be able to subscribe to and monitor all extensions that I specify. And this is also mentioned in CHANGES...
"It is now possible to specify a pattern match as a hint. Once a phone subscribes to something that matches the pattern a hint will be created using the contents and variables evaluated."

Until this feature was added, I must explicitly specify hints for every line, that I would like to subscribe and monitor, like this....
       hint(SIP/108) 108 => NoOP;
       hint(SIP/164) 164 => NoOP;
       hint(SIP/239) 239 => NoOP;
       hint(SIP/255) 255 => NoOP;
I hoped, that "pattern match as a hint" feature, solved this anoying requirement.

By: Tilghman Lesher (tilghman) 2008-09-05 23:30:43

pj:  I agree with you that it's a bug, if it's not acting correctly.  I disagree with your proposed solution.

By: pj (pj) 2008-09-06 04:37:19

Corydon76, I tried your patch  20080906__bug13327.diff.txt but it doesn't solve issue, instead it causes huge memory leak (allocations growing permanently in event.c), asterisk lockout and 100% load :(
'core show locks' output attached.

By: Tilghman Lesher (tilghman) 2008-11-07 14:00:50.000-0600

pj: this patch cannot do any of the things you suggest.  For one thing, the patch does not allocate any memory at all, so it could not be the cause of your memory leak.  However, I have since found a locking condition in the hints infrastructure, which is now fixed in trunk.  Could you re-evaluate this patch in the context of this change?

By: pj (pj) 2008-11-08 05:54:53.000-0600

Asterisk SVN-trunk-r155467 + 20080906__bug13327.diff.txt
it still doesn't work. it shows all subscribed extensions as idle, even if peer using this extension is unregistered.
it still causes asterisk lockout - uploading locks2.txt
when I'm testing same asterisk revision without this patch, memory leak doesn't eccur.

By: Digium Subversion (svnbot) 2008-12-10 16:48:18.000-0600

Repository: asterisk
Revision: 162922

U   trunk/main/pbx.c

r162922 | tilghman | 2008-12-10 16:48:18 -0600 (Wed, 10 Dec 2008) | 7 lines

Checking global variables here actually overwrote the previous substitution by
channel variables, and in any case, was redundant;
pbx_substitute_variables_helper ALREADY does substitution for global
(closes issue ASTERISK-12601)
Reported by: pj



By: pj (pj) 2008-12-11 16:51:38.000-0600

Asterisk SVN-trunk-r163094
two problems:
- when I try to subscribe to non-existent extension, it allows to subscribe to this ext. successfully and shows this extension as 'Idle'
- some locks occurs, when I do 'ael reload':

[Dec 11 21:44:14] ERROR[12000]: /root/src/asterisk163164/include/asterisk/lock.h:1236 _ast_rwlock_rdlock: pbx.c line 5226 (handle_show_hints): Error obtaining read lock: Resource temporarily unavailable
[Dec 11 21:44:14] ERROR[12000]: /root/src/asterisk163164/include/asterisk/lock.h:1105 _ast_rwlock_unlock: pbx.c line 5248 (handle_show_hints): rwlock '&(&hints)->lock' freed more times than we've locked!

=== Thread ID: -1217299568 (do_monitor           started at [20719] chan_sip.c restart_monitor())
=== ---> Lock #0 (astobj2.c): MUTEX 644 __ao2_callback c 0x83d0928 (1)
       asterisk(ast_bt_get_addresses+0x19) [0x8100319]
       asterisk [0x8082a20]
       asterisk(_ao2_lock+0x4a) [0x80828e3]
       asterisk [0x80844d4]
       asterisk(_ao2_callback+0x56) [0x80848c5]
       /usr/lib/asterisk/modules/chan_sip.so [0xb779f1ea]
       asterisk [0x8177481]
       /lib/i686/libpthread.so.0 [0xb7a31315]
       /lib/i686/libc.so.6(clone+0x5e) [0xb7cabdde]

By: Tilghman Lesher (tilghman) 2008-12-11 20:59:58.000-0600

pj:  if you have DETECT_DEADLOCKS defined in 'make menuselect', please turn it off.  It is the cause of the ERROR messages you're getting.

In terms of the subscription to the non-existent extension, that is not a problem on our end.  It simply means that your pattern match is too general.

By: pj (pj) 2008-12-12 01:33:06.000-0600

I haven't DETECT_DEADLOCKS in menuselect. Anyway, this is first case, when I hear, that I should disable some debug option to "resolve" asterisk locks.
Keep in mind, this is real lock situation, when asterisk is locked, it eg. doesn't accept sip registrations at all, imho, it's not only "cosmetic" thing.

By: Tilghman Lesher (tilghman) 2008-12-12 10:24:42.000-0600

In any case, the lock is not directly related to the issue you published here, so this issue is fixed.  If you wish to report another issue related to that lock, please open a new issue; do not reopen this one.