[Home]

Summary:ASTERISK-11181: core show channels becomes unresponsive - precursor to deadlock
Reporter:callguy (callguy)Labels:
Date Opened:2008-01-08 21:23:06.000-0600Date Closed:2008-04-25 07:11:54
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Core/Channels
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.4.19_lock_info.txt
( 1) 11712.patch
( 2) asterisk-1.4.18-fix-channel-find-locked-deadlock-skip.patch
( 3) csl.r105049
( 4) csl-01092008-2.txt
( 5) csl-02192007-1.4.18.txt
( 6) csl-02262008.txt
( 7) csl-1.4.18.txt
( 8) csl-jv-r105049.txt
( 9) gdb_dump.1182.txt
(10) gdb_dump.8151.txt
Description:After some period of time, core show channels will yield output, but not give a final channel count at the end. After that, the console simply hangs with no further output or commands possible. However, asterisk does continue to process calls successfully for some period of time after that before completely deadlocking (if you exit then bring up a new console you will see output again).

I suspect this may be a continuation of bug 11080 in some form, but it's not completely clear to me. I should also note that we are testing file's patch for 11687, but this didn't appear to be related as far as I could tell.

output of core show locks, and the info dump from ast_grab_core attached.
Comments:By: Russell Bryant (russell) 2008-01-09 16:01:05.000-0600

Did you compile with DONT_OPTIMIZE enabled?  Your backtrace is mostly empty ...
By: callguy (callguy) 2008-01-09 19:52:34.000-0600

yes - compiled with DONT_OPTIMIZE and DEBUG_THREADS. I just double checked.
By: Doug (doug) 2008-01-10 09:45:12.000-0600

I have the same problem but this only will start when a call gets locked in a queue as per ticket 11730. Can you confirm if you are getting a similar problem assuming you are using queues? A restart of asterisk is the only way to clear the lock in my case.
By: Mark Michelson (mmichelson) 2008-01-10 11:05:52.000-0600

From the output of core show locks, I have determined that the problem here is that in the function get_sip_pvt_byid_locked, both the sip_pvt_ptr and sip_pvt_ptr->owner get locked. For some reason, they are not getting unlocked, though. Because the sip_pvt_ptr->owner remains locked, the attempt to show channels falls into an infinite loop because it continually is attempting to lock that channel and failing.

The tricky part of this is figuring out why those locks were not released in a timely manner. I suspect that since you say that calls were still processed correctly that there are some missing unlock statements that need to be added. I could be wrong however, and it could be that chan_sip is hanging somewhere prior to the correct releasing points of those locks. What complicates this even further is that the only way get_sip_pvt_ptr_byid_locked is called is when a transfer is involved, meaning that keeping track of channel information through masquerades can be cumbersome.

By the way, I think you can avoid all those ??'s in the backtraces if instead of killing asterisk, you attach to the deadlocked asterisk process with gdb and get your backtraces there.
By: callguy (callguy) 2008-01-10 11:35:11.000-0600

thanks for the tip - i'll attach to the running process and grab the various backtraces. the only issue there is after it gets restarted there's no core file (though i suppose i could attach then use ast_grab_core anyway so there's at least something to see after the fact).

with respect to the rest of your description, i don't know if it's any help, but we've run into a whole bunch of possibly related stuff over the past while. bug 10595 in particular had to do with transferring into meetme and russell did something related to masquerading there. we've only seen this one intermittently, but it has been going on for a while (i've never reported it separately as it often seemed related to a different issue we were troubleshooting).
By: mattax (mattax) 2008-01-16 14:50:41.000-0600

Experiencing the same exact issue. When this happens, I have to do a kill -9 on the asterisk before I can restart it. I have asterisk 1.4.17 running on T1/PRI. This is a daily issue on a 50 user installation.


By: callguy (callguy) 2008-01-16 16:39:15.000-0600

mattax: can you make sure to compile with DEBUG_THREADS and DONT_OPTIMIZE selected, and upload the output of "core show locks" the next time it happens? Also - the server where it's happening to us is very busy so it's difficult to identify what exactly might be going on - if you have any sense from the console output what the cause might be that would be good too (in our case there's nothing specific we can find).
By: Caleb Pennington (appcontech) 2008-01-25 19:39:50.000-0600

I am experiencing the same issue on my Asterisk 1.4.17 and another server at a customer site running Asterisk 1.4.15.  They will run fine for a day or two and then we have people getting fast busy on incoming calls to the PRI and can't make outgoing calls.  I do a core show channels and I'll always see just one channel that shows up but isn't really active, because the phones don't display a connection and I have to restart Asterisk as a service for it to return to working order.  I spoke with my cousin and he has the same issues on his Asterisk 1.4 loads.  I never had this issue with 1.2.18 before upgrading to 1.4.17.
By: Tilghman Lesher (tilghman) 2008-02-06 19:01:21.000-0600

Is this still an issue with 1.4 SVN (soon to be 1.4.18)?  We fixed a major memory corruption issue that should take care of this and many other issues after the release of 1.4.17.
By: Andrew Pepler (pep) 2008-02-11 05:31:46.000-0600

I have this issue on 1.4.18
By: Norman Franke (norman) 2008-02-12 14:14:58.000-0600

I periodically get this under 1.4.18 as well. However, in my case, it appears a thread has died (corrupt stack.) I've been running under valgrind and it won't crash after almost 2 days. I did get some interesting results that I posted in ASTERISK-11408 which I think may be the same thing.

I think different threads are conflicting in their use of some objects, notably RTP object, and not locking. Before using valgrind, "core show channels" would freeze after my users reported they weren't getting calls.If I ran with DEBUG_THREADS, it never locked up, but I'd get other strange behavior that call processing would stop for 30 seconds to a minute with no apparent locks held, then release. So, I'm not running with DEBUG_THREADS anymore.
By: Tilghman Lesher (tilghman) 2008-02-12 16:17:28.000-0600

If you're having this issue, you're encouraged to likewise try out the patch in ASTERISK-11408
By: Andrew Pepler (pep) 2008-02-13 11:04:57.000-0600

The patch in 0011960 relates to SIP but all calls on my system use Zap channels so I presume that it would not help me.
By: Norman Franke (norman) 2008-02-13 14:03:36.000-0600

So you are app zap, no SIP at all? Maybe there are two issues, because the one I'm working on in ASTERISK-1189960 doesn't seem to have a lock on "channels" which is the other problem I have. This one never seems to show up under valgrind.

For me, it seems to be on incoming calls (at least once I know.)

Callguy's "core show locks" shows he's using SIP, at least. 1.4.18 may fix his issue.
By: callguy (callguy) 2008-02-13 14:14:33.000-0600

norman: we are using SIP only and haven't seen this as yet on 1.4.18, but this bug only occurs infrequently for us (so it's difficult to determine if it's been fixed or we just haven't hit it yet).

Has Corydon's patch resolved the problem for you?
By: Norman Franke (norman) 2008-02-13 14:39:07.000-0600

callguy- I'm afraid that patch has not fixed it. I am also SIP only.
By: Tilghman Lesher (tilghman) 2008-02-13 14:46:56.000-0600

norman:  are you referring to the patch uploaded today or just the patch from yesterday?
By: Norman Franke (norman) 2008-02-13 14:50:50.000-0600

Corydon76: See ASTERISK-1189960. I haven't yet been able to restart with the latest patch, but will shortly. The gist of my comment is that I don't think that will help based on the stack traces. You know more, so it may... It unfortunately takes a long time to reproduce.


By: mattax (mattax) 2008-02-14 13:27:25.000-0600

same issue on 1.4.18 as stated in the description


By: callguy (callguy) 2008-02-15 10:43:13.000-0600

Corydon76: We just experienced this on 1.4.18, I've attached the output from core show locks. I did not have the patch from 11960 installed, but will give that a try over the weekend.

norman: do you have any feedback on whether that patch resolved your issues?
By: Norman Franke (norman) 2008-02-15 11:39:14.000-0600

callguy- no that patch didn't help. I can't get it to hang under valgrind regardless of what I do.

Another bit of information. I think my last crash was during an outgoing call (to our SIP gateway.) When it hung, main/channels.c had locked the "channels" lock. I think the only place this happens on a new outgoing call is in ast_request. Perhaps channel_find_locked can be called, which also locks this. Everything else just locks for a very, very brief time. Unless another thread is overwriting memory, e.g. the problems in ASTERISK-11408

#0  ast_request (type=0xb6e92ae0 "SIP", format=4, data=0xb6e933f0, cause=0xb6e934f4) at channel.c:2944
#1  0xb72ca475 in dial_exec_full (chan=0xb71766c8, data=0xb6e95680, peerflags=0xb6e93550, continue_exec=0x0) at app_dial.c:1193
#2  0xb72ccf9a in dial_exec (chan=0xb71766c8, data=0xb6e95680) at app_dial.c:1760
#3  0x080bded6 in pbx_exec (c=0xb71766c8, app=0x82634f0, data=0xb6e95680) at pbx.c:532
#4  0x080c1023 in pbx_extension_helper (c=0xb71766c8, con=0x0, context=0xb7176848 "softphone", exten=0xb7176898 "221", priority=1,
   label=0x0, callerid=0xb7176ca0 "6107441333", action=E_SPAWN) at pbx.c:1851
ASTERISK-1  0x080c212c in ast_spawn_extension (c=0xb71766c8, context=0xb7176848 "softphone", exten=0xb7176898 "221", priority=1,
   callerid=0xb7176ca0 "6107441333") at pbx.c:2306
ASTERISK-2  0x080c266f in __ast_pbx_run (c=0xb71766c8) at pbx.c:2408
ASTERISK-3  0x080c33c5 in pbx_thread (data=0xb71766c8) at pbx.c:2623
ASTERISK-4  0x080fdf36 in dummy_start (data=0xb71776b8) at utils.c:852
ASTERISK-5  0xb7f9fb63 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-6 0xb7ecb18a in clone () from /lib/tls/libc.so.6
By: callguy (callguy) 2008-02-19 14:14:59.000-0600

Corydon76: We just hit this again - I uploaded the core show locks, and have just applied the patch from 11960, but from your comments there it seems that they may solved part of it but you are also working on something else related. Is there anything else we should be testing there?
By: Tilghman Lesher (tilghman) 2008-02-19 14:39:08.000-0600

callguy:  It appears that the locks are corrupt.  Could you try running under valgrind, as documented in doc/valgrind.txt ?
By: callguy (callguy) 2008-02-20 07:44:43.000-0600

Corydon76: I can try running valgrind in our development environment - the only issue is we see this only relatively infrequently on heavily loaded servers, so I'm not sure we'll be able to duplicate the conditions that are leading to the corruption.
By: Atis Lezdins (atis) 2008-02-20 08:02:54.000-0600

callguy,

could you try PBX testing framework (http://ftp.iq-labs.net/pbx-test/pbx-test-0.1.0.tar.gz) - create scripts that would match your environment and try to reproduce problem on your testing machine. then you'll be able to run valgrind with similar load.

it will of course take time to set it up, but i was in similar situation, and those valgrind logs actually helped to make our current 1.4.14 setup nearly rock-solid.
By: Digium Subversion (svnbot) 2008-02-25 17:15:25.000-0600

Repository: asterisk
Revision: 104102

U   branches/1.4/main/utils.c

------------------------------------------------------------------------
r104102 | russell | 2008-02-25 17:15:25 -0600 (Mon, 25 Feb 2008) | 7 lines

Improve the lock tracking code a bit so that a bunch of old locks that threads
failed to lock don't sit around in the history.  When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked.  If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue ASTERISK-11181)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=104102
By: Digium Subversion (svnbot) 2008-02-25 17:15:52.000-0600

Repository: asterisk
Revision: 104103

_U  trunk/
U   trunk/main/utils.c

------------------------------------------------------------------------
r104103 | russell | 2008-02-25 17:15:51 -0600 (Mon, 25 Feb 2008) | 15 lines

Merged revisions 104102 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r104102 | russell | 2008-02-25 17:19:05 -0600 (Mon, 25 Feb 2008) | 7 lines

Improve the lock tracking code a bit so that a bunch of old locks that threads
failed to lock don't sit around in the history.  When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked.  If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue ASTERISK-11181)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=104103
By: Russell Bryant (russell) 2008-02-25 17:17:19.000-0600

Could you update to the latest 1.4 code?  I tweaked the lock tracking code so that it will clean up the output a bit and should make it more helpful.  Also, while you're at it, the next time you get it locked up, after you get the "core show locks" output, go ahead and get a core dump using "ast_grab_core" and upload the backtrace.  I may also want to take a look at it using gdb, but we'll see.
By: callguy (callguy) 2008-02-26 17:38:14.000-0600

russell: we updated a few servers to the latest 1.4 code with your changes and haven't had any locks there. we did see a few locks on various servers on 1.4.18 again today - i noticed the gdb dump from one seemed to have more information than previously so i've attached it here in case there is anything useful. as soon as we get a lockup on one of the upgraded systems i'll post the output of core show locks. thanks!
By: Egbert Groot (wegbert) 2008-02-27 07:27:14.000-0600

We're experiencing the same sort of problems. First sign is the incomplete output from 'core show channels'. After a while the console doesn't do anything at all. Asterisk is compiled with DONT_OPTIMIZE, DEBUG_THREADS and DEBUG_CHANNEL_LOCKS. I'm not sure what exact situation leads to the lockup. However in the channel list that gets outputted by show channel, there is almost allways a couple of channels trying to 'Pickup()' a channel.
I suspect the channel to be picked up is a local channel dialed from a queue. This could by coincidential.
I can provide access to the machine when the lockup occurs, there's no need to quickly restart it.


By: Egbert Groot (wegbert) 2008-02-28 09:44:57.000-0600

Using svn version from yesterday (svn download reported revision 104534, 'show version on cli reports 'SVN-branch-1.4-r104334'), asterisk crashed with an segmentation fault:

Program terminated with signal 11, Segmentation fault.
#0  0xb7509bfe in __ast_pthread_mutex_lock (filename=0xb755bdf4 "chan_sip.c", lineno=1900, func=0xb755c318 "retrans_pkt",
   mutex_name=0xb755c324 "&pkt->owner->lock", t=0x0) at /usr/src/asterisk-1.4/include/asterisk/lock.h:302
302             int canlog = strcmp(filename, "logger.c") & t->track;

Coredump is avaible, I can submit 'thread apply all bt'  etc on request.


Edit: also posted as separate bug report 12098


By: Chase Venters (chaseventers) 2008-03-03 12:09:51.000-0600

putnopvut - we are experiencing this problem and I wanted to confirm that your remark about the channel_find_locked infinite loop is correct. If we turn on core debug, several threads can be seen trying to lock the same channel repeatedly in fast succession. The threads don't appear to ever recover - they seem to start over trying to lock the same channel, over and over...
By: Chase Venters (chaseventers) 2008-03-03 15:21:53.000-0600

I just submitted a patch that corrects what seems to be an obvious problem in channel_find_locked(). This is related to the infinite loop putnopvut described when a channel is deadlocked. It seems the channel_find_locked() function was intended to skip over a deadlocked channel but due to assigning prev instead of _prev, it is falling into an infinite loop.

I can imagine that this patch might at least keep "core show channels" or "Action: Status" in the manager from freezing if there are deadlocked channels, but it does not address why any such channels might be deadlocked, nor does it address the greater question of why a trylock()/usleep() loop is being used anyway. To that end, I don't feel that this patch is sufficient on which to close the ticket. It might just help keep the deadlock from becoming more evident in the rest of the process.
By: callguy (callguy) 2008-03-04 22:56:06.000-0600

russell: I managed to capture this happening against r105409, which has your revised lock tracking code. output of core show locks attached, hopefully this helps.
By: Joel Vandal (jvandal) 2008-03-07 08:16:17.000-0600

If this can help, I've upload (csl-jv-r105049.txt) the output of 'core show locks' on tested on r105049.
By: Joel Vandal (jvandal) 2008-03-11 12:46:00

Using the patch from 'asterisk-1.4.18-fix-channel-find-locked-deadlock-skip.patch'  fixed the 'core show channels' issue on all my test servers.
By: Josep Casals (josep) 2008-03-14 04:19:26

We also had this problem and the patch solved it for version 1.4.19rc2.
My question is whether this patch is going to be included in 1.4.19?


By: Joel Vandal (jvandal) 2008-03-14 11:09:24

This patch caused all issues about channels not hangup on my server, now all work PERFECTLY.
By: David Brillert (aragon) 2008-03-14 11:50:22

regarding jvandal's note: This patch caused all issues about channels not hangup on my server, now all work PERFECTLY.

For clarity...

jvandal means that removing patch from 11712 asterisk-1.4.18-fix-channel... and using 12098-putnopvutv3.patch from bug 12098 and atis' http://bugs.digium.com/view.php?id=12127#83966 suggestions in bug 12127 fixed the problems for us using asterisk 1.4
By: Chase Venters (chaseventers) 2008-03-14 12:02:33

It looks like bug 0012127 is a separate issue, at least based on putnopvut's comments about a problem in the channel locking in SIP where transfers are involved.

It is of course possible for other issues to manifest themselves as problems here. channel_find_locked isn't a source of problems itself per se - it's just that a deadlocked channel would cause a deadlock there.

Asterisk included a hack to try and avoid deadlocks in channel_find_locked if a channel was left locked, but it had a bug that caused locked channels to send it into an infinite loop. asterisk-1.4.18-fix-channel-find-locked-deadlock-skip.patch just fixed that hack so that it would actually skip deadlocked channels. Deadlocked channels could naturally cause problems elsewhere.

I'm personally uncomfortable with the idea of a trylock()/usleep() for loop, figuring that at least it should be a timedlock and at best such hacks shouldn't be used at all. But so long as the patch stops deadlocks from causing larger problems in the rest of the PBX, I'm running it on our production system, pending a real fix for this channel deadlock issue.
By: callguy (callguy) 2008-03-19 09:54:45

we just had this happen again, looks very similar to jvandal's core show locks. if providing access to the server would be helpful i can arrange to do that.
By: Mark Michelson (mmichelson) 2008-04-02 13:36:10

If it's any consolation, the latest core show locks output here from jvandal (csl-jv-r105049) is the same as the output on issue number ASTERISK-11730, for which there is a patch to try testing.
By: Mark Michelson (mmichelson) 2008-04-07 17:54:18

Issue 12307 has now been closed, so I am curious to know if this issue should also be closed.
By: Doug (doug) 2008-04-17 05:39:19

We had another occourence of this happen today on ver 1.4.19 I have attached the "core show locks" info. Please let me know if this helps? File name 1.4.19 lock info.txt


By: Mark Michelson (mmichelson) 2008-04-17 10:00:20

Try using 11712.patch. That should clear up the deadlock that was just reported.
By: Jason Parker (jparker) 2008-04-23 16:55:26

DougUDI, have you been able to test 11712.patch?
By: Alistair Cunningham (acunningham) 2008-04-23 17:03:13

We have tried this patch on several machines suffering from ASTERISK-10707, and initial testing is positive - the machines have been stable and have suffered from no lockups.
By: Digium Subversion (svnbot) 2008-04-24 14:59:07

Repository: asterisk
Revision: 114624

U   branches/1.4/channels/chan_local.c

------------------------------------------------------------------------
r114624 | mmichelson | 2008-04-24 14:59:07 -0500 (Thu, 24 Apr 2008) | 10 lines

Resolve a deadlock in chan_local by releasing the channel lock
temporarily.

(closes issue ASTERISK-11181)
Reported by: callguy
Patches:
     11712.patch uploaded by putnopvut (license 60)
Tested by: acunningham


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114624
By: Digium Subversion (svnbot) 2008-04-24 15:00:50

Repository: asterisk
Revision: 114625

_U  trunk/
U   trunk/channels/chan_local.c

------------------------------------------------------------------------
r114625 | mmichelson | 2008-04-24 15:00:49 -0500 (Thu, 24 Apr 2008) | 18 lines

Merged revisions 114624 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114624 | mmichelson | 2008-04-24 15:04:24 -0500 (Thu, 24 Apr 2008) | 10 lines

Resolve a deadlock in chan_local by releasing the channel lock
temporarily.

(closes issue ASTERISK-11181)
Reported by: callguy
Patches:
     11712.patch uploaded by putnopvut (license 60)
Tested by: acunningham


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114625
By: Digium Subversion (svnbot) 2008-04-24 15:01:26

Repository: asterisk
Revision: 114626

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_local.c

------------------------------------------------------------------------
r114626 | mmichelson | 2008-04-24 15:01:25 -0500 (Thu, 24 Apr 2008) | 26 lines

Merged revisions 114625 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r114625 | mmichelson | 2008-04-24 15:06:06 -0500 (Thu, 24 Apr 2008) | 18 lines

Merged revisions 114624 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114624 | mmichelson | 2008-04-24 15:04:24 -0500 (Thu, 24 Apr 2008) | 10 lines

Resolve a deadlock in chan_local by releasing the channel lock
temporarily.

(closes issue ASTERISK-11181)
Reported by: callguy
Patches:
     11712.patch uploaded by putnopvut (license 60)
Tested by: acunningham


........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114626
By: Digium Subversion (svnbot) 2008-04-25 07:11:54

Repository: asterisk
Revision: 114643

_U  team/seanbright/resolve-shadow-warnings/
U   team/seanbright/resolve-shadow-warnings/apps/app_alarmreceiver.c
U   team/seanbright/resolve-shadow-warnings/apps/app_chanspy.c
U   team/seanbright/resolve-shadow-warnings/apps/app_dial.c
U   team/seanbright/resolve-shadow-warnings/apps/app_disa.c
U   team/seanbright/resolve-shadow-warnings/apps/app_externalivr.c
U   team/seanbright/resolve-shadow-warnings/apps/app_followme.c
U   team/seanbright/resolve-shadow-warnings/apps/app_meetme.c
U   team/seanbright/resolve-shadow-warnings/apps/app_queue.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_alsa.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_gtalk.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_h323.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_iax2.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_jingle.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_local.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_mgcp.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_misdn.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_oss.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_sip.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_skinny.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_unistim.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_zap.c
U   team/seanbright/resolve-shadow-warnings/include/asterisk/channel.h
U   team/seanbright/resolve-shadow-warnings/include/asterisk/manager.h
U   team/seanbright/resolve-shadow-warnings/main/channel.c
U   team/seanbright/resolve-shadow-warnings/main/http.c
U   team/seanbright/resolve-shadow-warnings/main/manager.c
U   team/seanbright/resolve-shadow-warnings/res/res_musiconhold.c

------------------------------------------------------------------------
r114643 | seanbright | 2008-04-25 07:11:47 -0500 (Fri, 25 Apr 2008) | 263 lines

Merged revisions 114585,114588,114592,114595,114598,114601,114604,114606,114609,114612,114617,114622,114625,114629,114633,114635,114637 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r114585 | oej | 2008-04-23 12:53:34 -0400 (Wed, 23 Apr 2008) | 10 lines

Merged revisions 114584 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114584 | oej | 2008-04-23 18:51:41 +0200 (Ons, 23 Apr 2008) | 2 lines

Add 502 support for both directions, not only one...  (see r114571)

........

................
r114588 | russell | 2008-04-23 13:18:29 -0400 (Wed, 23 Apr 2008) | 10 lines

Merged revisions 114587 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114587 | russell | 2008-04-23 12:16:32 -0500 (Wed, 23 Apr 2008) | 2 lines

Fix find_callno_locked() to actually return the callno locked in some more cases.

........

................
r114592 | russell | 2008-04-23 14:01:00 -0400 (Wed, 23 Apr 2008) | 13 lines

Merged revisions 114591 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114591 | russell | 2008-04-23 12:55:31 -0500 (Wed, 23 Apr 2008) | 5 lines

Store the manager session ID explicitly as 4 byte ID instead of a ulong.  The
mansession_id cookie is coded to be limited to 8 characters of hex, and this
could break logins from 64-bit machines in some cases.
(inspired by AST-20)

........

................
r114595 | qwell | 2008-04-23 14:33:28 -0400 (Wed, 23 Apr 2008) | 16 lines

Merged revisions 114594 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114594 | qwell | 2008-04-23 13:28:44 -0500 (Wed, 23 Apr 2008) | 8 lines

Fix reload/unload for res_musiconhold module.

(closes issue ASTERISK-11060)
Reported by: sunder
Patches:
     M11575_14_rev3.diff uploaded by junky (license 177)
     bug11575_trunk.diff.txt uploaded by jamesgolovich (license 176)

........

................
r114598 | russell | 2008-04-23 16:53:05 -0400 (Wed, 23 Apr 2008) | 18 lines

Merged revisions 114597 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114597 | russell | 2008-04-23 15:49:18 -0500 (Wed, 23 Apr 2008) | 10 lines

Fix an issue that caused getting the correct next channel to not always work.
Also, remove setting the amount of time to wait for a digit from 5 seconds back
down to 1/10 of a second.  I believe this was so the beep didn't get played over
and over really fast, but a while back I put in another fix for that issue.

(closes issue ASTERISK-11895)
Reported by: jsmith
Patches:
     app_chanspy_channel_walk.trunk.patch uploaded by jsmith (license 15)

........

................
r114601 | russell | 2008-04-23 18:53:20 -0400 (Wed, 23 Apr 2008) | 14 lines

Merged revisions 114600 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114600 | russell | 2008-04-23 17:18:12 -0500 (Wed, 23 Apr 2008) | 6 lines

Improve some broken cookie parsing code.  Previously, manager login over HTTP
would only work if the mansession_id cookie was first.  Now, the code builds
a list of all of the cookies in the Cookie header.  This fixes a problem
observed by users of the Asterisk GUI.
(closes AST-20)

........

................
r114604 | russell | 2008-04-24 10:55:21 -0400 (Thu, 24 Apr 2008) | 3 lines

Change a verbose message to debug.
(closes issue ASTERISK-11911)

................
r114606 | oej | 2008-04-24 10:59:05 -0400 (Thu, 24 Apr 2008) | 11 lines

Merged revisions 114603 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114603 | oej | 2008-04-24 16:55:18 +0200 (Tor, 24 Apr 2008) | 3 lines

Only have one max-forwards header in outbound REFERs.
Discovered in the Asterisk SIP Masterclass in Orlando. Thanks Joe!

........

................
r114609 | russell | 2008-04-24 11:56:55 -0400 (Thu, 24 Apr 2008) | 12 lines

Merged revisions 114608 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114608 | russell | 2008-04-24 10:55:21 -0500 (Thu, 24 Apr 2008) | 4 lines

Fix a silly mistake in a change I made yesterday that caused chan_iax2 to blow
up very quickly.
(issue ASTERISK-11912)

........

................
r114612 | qwell | 2008-04-24 12:47:01 -0400 (Thu, 24 Apr 2008) | 17 lines

Merged revisions 51989 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

(closes issue ASTERISK-11893)
Reported by: daniele
Patches:
     misdn-moh-1.6.0-beta7.1.patch uploaded by daniele (license 471)
Tested by: daniele

Technically, I didn't use the patch above except to find out what revision to merge - but it's the same thing as this revision.

........
r51989 | crichter | 2007-01-24 06:57:22 -0600 (Wed, 24 Jan 2007) | 1 line

added fix from ASTERISK-8652
........

................
r114617 | tilghman | 2008-04-24 15:24:31 -0400 (Thu, 24 Apr 2008) | 6 lines

Fix DST calculation, and fix bug in calculation of whether conf has started yet or not
(Closes issue ASTERISK-11715)
Reported by: DEA
Patches:
      app_meetme-rt-dst-sched-fix.txt uploaded by DEA (license 3)

................
r114622 | tilghman | 2008-04-24 15:54:57 -0400 (Thu, 24 Apr 2008) | 12 lines

Merged revisions 114621 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114621 | tilghman | 2008-04-24 14:53:36 -0500 (Thu, 24 Apr 2008) | 4 lines

Ensure that when we set the accountcode, it actually shows up in the CDR.
(Fix for AMI Originate)
(Closes issue ASTERISK-11451)

........

................
r114625 | mmichelson | 2008-04-24 16:06:06 -0400 (Thu, 24 Apr 2008) | 18 lines

Merged revisions 114624 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114624 | mmichelson | 2008-04-24 15:04:24 -0500 (Thu, 24 Apr 2008) | 10 lines

Resolve a deadlock in chan_local by releasing the channel lock
temporarily.

(closes issue ASTERISK-11181)
Reported by: callguy
Patches:
     11712.patch uploaded by putnopvut (license 60)
Tested by: acunningham


........

................
r114629 | mmichelson | 2008-04-24 16:43:52 -0400 (Thu, 24 Apr 2008) | 16 lines

Merged revisions 114628 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114628 | mmichelson | 2008-04-24 15:43:03 -0500 (Thu, 24 Apr 2008) | 8 lines

Output of channel variables when eventwhencalled=vars was set
was being truncated two characters. This patch corrects the
problem.

(closes issue ASTERISK-11891)
Reported by: davidw


........

................
r114633 | mmichelson | 2008-04-24 17:35:39 -0400 (Thu, 24 Apr 2008) | 19 lines

Merged revisions 114632 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114632 | mmichelson | 2008-04-24 16:35:08 -0500 (Thu, 24 Apr 2008) | 11 lines

Re-invite RTP during a masquerade so that, for instance, an AMI
redirect of two channels which are natively bridged will preserve audio
on both channels. This prevents a problem with Asterisk not re-inviting
due to one of the channels having being a zombie.

(closes issue ASTERISK-11910)
Reported by: mneuhauser
Patches:
     asterisk-1.4-114602_restore-RTP-on-fixup.patch uploaded by mneuhauser (license 425)


........

................
r114635 | file | 2008-04-24 18:11:46 -0400 (Thu, 24 Apr 2008) | 4 lines

Hey look, it builds.
(closes issue ASTERISK-11916)
Reported by: falves11

................
r114637 | mvanbaak | 2008-04-24 18:16:48 -0400 (Thu, 24 Apr 2008) | 8 lines

Pass the hangup cause all the way to the calling app/channel.

(closes issue ASTERISK-10842)
Reported by: rain
Patches:
     20071207__pass_cause_in_hangup_control_frame.diff.txt uploaded by Corydon76 (license 14)
brought up-to-date to trunk by me

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114643