[asterisk-dev] System/SHELL in redirecting macro hangs asterisk

[J.A. Bezemer]

On Sun, 23 Sep 2012, Tzafrir Cohen wrote:

> On Mon, Sep 17, 2012 at 03:31:19PM +0200, J.A. Bezemer wrote:
>>
>> Hi all,
>>
>> Asterisk 1.8.8.0 on Debian 6.0.5, stock Debian-backports kernel
>> 2.6.39-bpo.2-486.
>>
>> Three SIP phones: 123, 456 and 789. All have sendrpid=pai.
>>
>> Phone 456 is set to unconditionally forward all calls to 789; it
>> correctly says 302 "Moved Temporarily".
>>
>> Minimal dialplan:
>>
>> [fromsip]
>> exten => 456,1,NoOp(This is ${CONTEXT}:${EXTEN})
>> exten => 456,n,Set(__REDIRECTING_CALLER_SEND_MACRO=redirtest1)
>> exten => 456,n,Set(__REDIRECTING_CALLEE_SEND_MACRO=redirtest1)
>> exten => 456,n,Dial(SIP/456)
>> exten => 789,1,NoOp(This is ${CONTEXT}:${EXTEN})
>> exten => 789,n,Dial(SIP/789)
>>
>> [macro-redirtest1]
>> exten => s,1,NoOp(This is ${CONTEXT}:${EXTEN})
>> ;exten => s,n,System(/bin/true)  ; HANGS asterisk
>> ;exten => s,n,Set(DUMMY=${SHELL(echo abc)})  ; HANGS asterisk
>
> What do you see in strace? What is asterisk hung on?
>
> What if you use 'touch /tmp/test' instead? Does asterisk hang before, at or
> after the shell command?
>
>>
>>
>> Phone 123 dials 456. Phone 456 forwards the call to 789.
>>
>> Once I use System or SHELL in the redirecting macro, asterisk will
>> hang on it. Actually, console will still work, but no SIP traffic is
>> processed at all and that's all I can test with.

Over the weekend I finally managed to do some debugging. Deadlock occurrs 
in the pbx_builtin_setvar_helper() call by 
app_system.c:system_exec_helper() when it is trying to set SYSTEMSTATUS 
channelvar after command execution has completed. The lock is being held 
by ast_channel_trylock(in) in app_dial.c:do_forward() -- and the lock is 
released there only *after* ast_channel_redirecting_macro() is called. 
This is Asterisk 1.8.8.0.

While investigating, I noticed that 1.8.16.0 has significant changes in 
do_forward(), including unlocking both "c" and "in" before the redirecting 
macro gets called. So I updated to 1.8.16.0 and indeed, the deadlock is 
gone.

Conclusion: Case closed. And thanks for your attention, much appreciated.


Best regards,

Anne Bezemer