[Home]

Summary:ASTERISK-10227: Meetme with Redirect leaves channel after hangup and crashes
Reporter:Atis Lezdins (atis)Labels:
Date Opened:2007-09-04 07:30:46Date Closed:2007-09-13 08:40:45
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_meetme
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) backtrace.txt
( 1) cli_output.txt.gz
( 2) dialplan_2.tar.gz
( 3) full_last_call.gz
( 4) full.1.gz
( 5) full.2.gz
( 6) full.3.gz
( 7) full.4.gz
Description:Scenario:
1) SIP/21167 dials to SIP/21168
2) I'm sending a manager action Redirect, with both open channels to context that sends them to meetme room.
3) Caller hears "you are only person", this creates 3rd Zap/pseudo channel.
4) Both channels go to meetme room, they talk
5) On hangup, very often, but not every time third pseudo channel is left.

Repeating this scenario for several times (from 2 up to more than 40), makes asterisk crash.

For this, it is important that there is prompt "only person" played, without this prompt (if in unaccessible format or removed) there isn't third pseudo channel, and crashes haven't been noticed (for over than consecutive 10 calls)

I will attach example dialplan with php script - redirect.php that takes first two active channels and sends them to meetme room. This is minimal asterisk configuration that actually makes asterisk to crash. On my complete dialplan crashes are happening more often (usually at second hangup).

I first tested it with Asterisk 1.4.10, but today i tested with latest version from SVN (branch 1.4). I enabled DEBUG_CHANNEL_LOCKS, DEBUG_THREADS and DONT_OPTIMIZE in menuselect. Also i did "core show channels verbose" and "core show locks" after every call (almost). I will attach full log, and CLI output.

Unfortunately, no core was dumped (i used ulimit -u unlimited). Also at some point one call didn't got hanged up, and there were two AsyncGoto channels left, i tried (unsuccessfully) to kill them with soft hangup - i'm not sure that it won't make log worse. If it is bad, i can do another testing (it takes several hours)

Similar problem was also noted in bug ASTERISK-7182 in first comment, but nobody made an issue of that, as that was a new experimental application.

****** STEPS TO REPRODUCE ******

There was a race condition to create the recordthread if multiple channels entered a new conference at the same time.  This is fixed in 1.4 branch revision 82286.  thank you for the redirect.php script, it was very helpful for reproducing the issue.
Comments:By: Atis Lezdins (atis) 2007-09-04 07:47:51

Just to include this issue in search engines:

Significant errors before crash:

WARNING[19894] channel.c: Hard hangup called by thread -1214784624 on Zap/pseudo-994643193, while fd is blocked by thread -1213555824 in procedure ast_waitfor_nandfds!  Expect a failure
...
ERROR[19903] /usr/dist/asterisk-svn-1.4/include/asterisk/lock.h: channel.c line 4879 (ast_channel_lock): Error obtaining mutex: Invalid argument

I will provide full asterisk log within a short time. For now - last lines before crash are in full_last_call.gz
By: Atis Lezdins (atis) 2007-09-04 08:49:36

I just noticed that console shows:
Asterisk SVN-branch-1.4-r78646, Copyright (C) 1999 - 2007 Digium, Inc. and others.

However svn info shows 81434. Have i reported revision correctly?


By: Atis Lezdins (atis) 2007-09-04 09:30:17

I'm sorry, i was quite foolish and launched asterisk from non-writable directory, so i didn't get core. Now i crashed it again (with my regular dialplan - as it's faster), and attached a backtrace.

Also, while testing i found problem that caused AsyncGoto channels to appear. It happened because i redirected two Zap/pseudo channels to meetme room. This doesn't  impact crashing in any way - i tested everything again, without this - asterisk still crashes. So, i also attached dialplan_2.tar.gz that have fixed php script.
Please delete dialplan.tar.gz

Additionally, i attached full log of asterisk, while crashing it, with more than 30 consecutive calls..

P.S.
There is bug in Mantis, i can't upload gzip that is a little bit more than megabyte - i get some SQL error with gzip in output ;)
By: Clod Patry (junky) 2007-09-06 17:45:24

Could you guys try the patch from ASTERISK-10185 and see how it goes?


By: Atis Lezdins (atis) 2007-09-07 10:45:30

I already posted in ASTERISK-1060661 that it's unrelated. Also tested today on revision 81885 (SVN-branch-1.4-r81832).

I think this is problem with mentioned third pseudo channel.
By: Dwayne Hubbard (dhubbard) 2007-09-10 17:01:02

FYI - I'm now able to reproduce this and agree that it has something to do with the lingering and accumulating pseudo channels; but I'm not sure what the problem is yet.
By: Atis Lezdins (atis) 2007-09-11 04:38:27

Ok, then it is probably good news.

You can try to add it all to some existing (preferrably complex) dialplan, that way you would get crashes much faster. On my regular dialplan they happen almost every 2 calls.
By: Dwayne Hubbard (dhubbard) 2007-09-12 15:34:28

This is fixed in 1.4 revision 82286 and trunk 82287
By: Atis Lezdins (atis) 2007-09-13 08:28:32

Thanks, it seems to be fixed. I hope it'll get into 1.4.12. I did 10 tests (usually crash should be after two), and no extra channels, no crashes. Thank you.
By: Dwayne Hubbard (dhubbard) 2007-09-13 08:40:45

from the last note, it seems that this issue was reopened accidentally, so I'm going to close it again.