[Home]

Summary:ASTERISK-14332: Deadlock in do_monitor() of chan_sip
Reporter:Samy Kamkar (samyk)Labels:
Date Opened:2009-06-17 22:08:43Date Closed:2011-07-27 13:33:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_dahdi.txt
( 1) chan_sip.txt
( 2) tbelder-core_show_locks.txt
( 3) tbelder-gdbtrace.txt
Description:Unfortunately I have no steps to reproduce this. Had about 30 calls going through, all calls are SIP, and randomly ran into a SIP deadlock (`sip show channels` would cause console to hang, no new SIP calls would begin).

It sort of looks like `dialoglist` is an infinite loop (every member points to at least one other member, there is never a ->next that points to null), but I don't see how that could happen in the code so I'm not sure.

I did get `core show locks` output a few times, and I have a modified version that provides the time of the last time each lock was locked/unlocked. This is interesting because we can see lock #0 never changes and is held for multiple minutes before I restart, but lock #1 changes constantly.

The fact that lock #1 (lock on dialog->sip_pvt) is constantly changing in do_monitor makes me think `dialoglist` is an infinite loop.

****** ADDITIONAL INFORMATION ******

chan_sip.c is slightly modified in my case so line numbers won't match (I have the SIPRemoveHeader patch applied and a few other minor differences in irrelevant code). Additionally, I am *not* using the SIPRemoveHeader function at all -- it was never called.

Here are some chan_sip.c line numbers for relevance:
19416: restartsearch:
19417:        /* Check for dialogs needing to be killed */
19418:        dialoglist_lock();
19419:        t = time(NULL);          
...
19424:        for (dialog = dialoglist; dialog; dialog = dialog->next) {      
19425:            if (sip_pvt_trylock(dialog)) {
19426:                dialoglist_unlock();                                    
19427:                usleep(1);    

The lock messages began to appear at 17:29:49:
[Jun 17 17:29:44] VERBOSE[29459] logger.c:     -- Executing [s@neoagent:370] ChanIsAvail("Local/ASTERISK-3932#108852@neoagent-47eb;2
", "SIP/00085D19F2F7,tn,neoagent") in new stack
[Jun 17 17:29:44] VERBOSE[29459] logger.c:   == Using SIP RTP CoS mark 5
[Jun 17 17:29:49] ERROR[29459] /root/ast16/trunk/include/asterisk/lock.h: chan_sip.c line 6073 (sip_alloc): Deadlock? waited 5 sec for mutex '&dialoglock'?
[Jun 17 17:29:49] ERROR[29459] /root/ast16/trunk/include/asterisk/lock.h: chan_sip.c line 19418 (do_monitor): '&dialoglock' was locked here.


Here is a `core show locks` at 17:36:09 -- note that the other numbers are timestamps in epoch of when the lock was created and last unlocked (if applicable). What's really interesting is timestamp for lock #0 never changes (makes sense) but lock #1's timestamp is constantly updating -- makes me think line 19424 is an infinite loop.
=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr>
=== <last locked>, <unlocked> (times locked)
===
=== Thread ID: -1224737872 (do_monitor           started at [19485] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 19418 do_monitor &dialoglock 0x4baee0
===      1245284978, 0 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 19425 do_monitor &dialog->pvt_lock 0x8bcedb4
===      1245285369, 1245284978 (1)
=== -------------------------------------------------------------------
===
=== Thread ID: -1372193872 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: -1224983632 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)
... this goes on with the same lock trying to be accessed ...



At 17:36:20, it looks like this:
=== Thread ID: -1224737872 (do_monitor           started at [19485] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 19418 do_monitor &dialoglock 0x4baee0
===      1245284978, 0 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 19425 do_monitor &dialog->pvt_lock 0x8f5960c
===      1245285380, 1245284978 (1)
=== -------------------------------------------------------------------
===
=== Thread ID: -1372193872 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: -1224983632 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)


And at 17:37:45:
=== Thread ID: -1224737872 (do_monitor           started at [19485] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 19418 do_monitor &dialoglock 0x4baee0
===      1245284978, 0 (1)
=== ---> Waiting for Lock #1 (chan_sip.c): MUTEX 19425 do_monitor &dialog->pvt_lock 0xb0ffe044
===      1245285465, 1245284978 (1)
=== --- ---> Locked Here: chan_sip.c line 19425 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: -1372193872 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: -1224983632 (pbx_thread           started at [ 3995] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 6073 sip_alloc &dialoglock 0x4baee0
===      1245284984, 0 (1)
=== --- ---> Locked Here: chan_sip.c line 19418 (do_monitor)



I attempted to get a core, but something wacky happened and the core seems useless (only one thread with no information):
Wed Jun 17 17:37:04 2009
(gdb) file /usr/sbin/asterisk
GNU gdb Red Hat Linux (6.3.0.0-1.96rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
Reading symbols from /usr/sbin/asterisk...
done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) attach 5084
Attaching to program: /usr/sbin/asterisk, process 5084
0x005a67a2 in ?? ()
(gdb) generate-core-file
Saved corefile core.5084

...
(gdb) file /usr/sbin/asterisk
GNU gdb Red Hat Linux (6.3.0.0-1.96rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
Reading symbols from /usr/sbin/asterisk...
done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) core-file core.5084
Core was generated by `/usr/sbin/asterisk'.
#0  0x005a67a2 in ?? ()
(gdb) info thread
* 1 process 5084  0x005a67a2 in ?? ()
(gdb) thread apply all bt
Thread 1 (process 5084):
#0  0x005a67a2 in ?? ()
#1  0x00000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (process 5084)]#0  0x005a67a2 in ?? ()
(gdb) frame
#0  0x005a67a2 in ?? ()

Deadlocked thread 1 (thread ID 5084, frame )

Thread 1 (process 5084):
#0  0x005a67a2 in ?? ()
#1  0x00000000 in ?? ()

Comments:By: Samy Kamkar (samyk) 2009-06-17 22:10:23

Above, I mention I think dialoglist is an infinite loop. I do NOT know this for sure, it's just an estimation based on what I'm seeing in the locks and the timestamps associated.

I would have checked in gdb but you can see above my core was useless.
By: Mark Michelson (mmichelson) 2009-06-22 09:24:53

I believe this is the same issue as ASTERISK-14328. I'll mark them as related.


By: Mark Michelson (mmichelson) 2009-06-22 09:25:43

Oh, also, since the fix on ASTERISK-14328 seems to be working for the reporter, I may close this issue too when the fix is committed. If you should find that the fix does not solve your problem, please feel free to re-open this.


By: Digium Subversion (svnbot) 2009-06-22 09:34:10

Repository: asterisk
Revision: 202336

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines

Fix a possible infinite loop in SDP parsing during glare situation.

There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.

(closes issue ASTERISK-14217)
Reported by: schmidts

(closes issue ASTERISK-14332)
Reported by: samy

(closes issue ASTERISK-13569)
Reported by: pj

(closes issue ASTERISK-14328)
Reported by: aragon
Patches:
     sip_inf_loop.patch uploaded by mmichelson (license 60)
Tested by: aragon


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

http://svn.digium.com/view/asterisk?view=rev&revision=202336
By: Digium Subversion (svnbot) 2009-06-22 09:35:12

Repository: asterisk
Revision: 202337

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r202337 | mmichelson | 2009-06-22 09:35:10 -0500 (Mon, 22 Jun 2009) | 31 lines

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

........
 r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
 
 Fix a possible infinite loop in SDP parsing during glare situation.
 
 There was a while loop in get_ip_and_port_from_sdp which was controlled
 by a call to get_sdp_iterate. The loop would exit either if what we were
 searching for was found or if the return was NULL. The problem is that
 get_sdp_iterate never returns NULL. This means that if what we were searching
 for was not present, the loop would run infinitely. This modification of the
 loop fixes the problem.
 
 (closes issue ASTERISK-14217)
 Reported by: schmidts
 
 (closes issue ASTERISK-14332)
 Reported by: samy
 
 (closes issue ASTERISK-13569)
 Reported by: pj
 
 (closes issue ASTERISK-14328)
 Reported by: aragon
 Patches:
       sip_inf_loop.patch uploaded by mmichelson (license 60)
 Tested by: aragon
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=202337
By: Digium Subversion (svnbot) 2009-06-22 09:35:37

Repository: asterisk
Revision: 202338

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

------------------------------------------------------------------------
r202338 | mmichelson | 2009-06-22 09:35:35 -0500 (Mon, 22 Jun 2009) | 38 lines

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

................
 r202337 | mmichelson | 2009-06-22 09:35:09 -0500 (Mon, 22 Jun 2009) | 31 lines
 
 Merged revisions 202336 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
   
   Fix a possible infinite loop in SDP parsing during glare situation.
   
   There was a while loop in get_ip_and_port_from_sdp which was controlled
   by a call to get_sdp_iterate. The loop would exit either if what we were
   searching for was found or if the return was NULL. The problem is that
   get_sdp_iterate never returns NULL. This means that if what we were searching
   for was not present, the loop would run infinitely. This modification of the
   loop fixes the problem.
   
   (closes issue ASTERISK-14217)
   Reported by: schmidts
   
   (closes issue ASTERISK-14332)
   Reported by: samy
   
   (closes issue ASTERISK-13569)
   Reported by: pj
   
   (closes issue ASTERISK-14328)
   Reported by: aragon
   Patches:
         sip_inf_loop.patch uploaded by mmichelson (license 60)
   Tested by: aragon
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=202338
By: Digium Subversion (svnbot) 2009-06-22 09:36:02

Repository: asterisk
Revision: 202339

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r202339 | mmichelson | 2009-06-22 09:36:00 -0500 (Mon, 22 Jun 2009) | 38 lines

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

................
 r202337 | mmichelson | 2009-06-22 09:35:09 -0500 (Mon, 22 Jun 2009) | 31 lines
 
 Merged revisions 202336 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
   
   Fix a possible infinite loop in SDP parsing during glare situation.
   
   There was a while loop in get_ip_and_port_from_sdp which was controlled
   by a call to get_sdp_iterate. The loop would exit either if what we were
   searching for was found or if the return was NULL. The problem is that
   get_sdp_iterate never returns NULL. This means that if what we were searching
   for was not present, the loop would run infinitely. This modification of the
   loop fixes the problem.
   
   (closes issue ASTERISK-14217)
   Reported by: schmidts
   
   (closes issue ASTERISK-14332)
   Reported by: samy
   
   (closes issue ASTERISK-13569)
   Reported by: pj
   
   (closes issue ASTERISK-14328)
   Reported by: aragon
   Patches:
         sip_inf_loop.patch uploaded by mmichelson (license 60)
   Tested by: aragon
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=202339
By: Digium Subversion (svnbot) 2009-06-22 09:36:29

Repository: asterisk
Revision: 202340

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r202340 | mmichelson | 2009-06-22 09:36:26 -0500 (Mon, 22 Jun 2009) | 38 lines

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

................
 r202337 | mmichelson | 2009-06-22 09:35:09 -0500 (Mon, 22 Jun 2009) | 31 lines
 
 Merged revisions 202336 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
   
   Fix a possible infinite loop in SDP parsing during glare situation.
   
   There was a while loop in get_ip_and_port_from_sdp which was controlled
   by a call to get_sdp_iterate. The loop would exit either if what we were
   searching for was found or if the return was NULL. The problem is that
   get_sdp_iterate never returns NULL. This means that if what we were searching
   for was not present, the loop would run infinitely. This modification of the
   loop fixes the problem.
   
   (closes issue ASTERISK-14217)
   Reported by: schmidts
   
   (closes issue ASTERISK-14332)
   Reported by: samy
   
   (closes issue ASTERISK-13569)
   Reported by: pj
   
   (closes issue ASTERISK-14328)
   Reported by: aragon
   Patches:
         sip_inf_loop.patch uploaded by mmichelson (license 60)
   Tested by: aragon
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=202340
By: Samy Kamkar (samyk) 2009-06-22 12:31:57

Hi mmichelson,

Thanks for the help. Unfortunately I can't reproduce the issue (with or without a patch), so I can't confirm or deny this patch.

However, I looked at this patch and the other three related reports. Those three reports are all locked on 'netlock' from restart_monitor, while my report seems to be locked on a different lock (dialoglock) from do_monitor. It seems to look like it's an issue in a different location. I also haven't found any path from the location of the lock to any of the handle_* functions (which in turn call process_sdp() which in turn hits the infinite while). I also had three different "core show locks" at three different times all displaying the same locks.

Do you know if there is actually a path for that section of code in do_monitor's "restartsearch" goto that could create this lock?

Thanks!
By: Mark Michelson (mmichelson) 2009-06-23 18:20:09

I believe you are correct that the bug I fixed is not the same you are seeing here.

Given that the address of the sip_pvt being locked inside of do_monitor is different with each subsequent "core show locks" output, I agree that you are probably seeing an infinite loop while trying to traverse the list of sip_pvts. A quick look through the code has not yet shown me how this could happen. I'll take a closer look when I get a chance.
By: Samy Kamkar (samyk) 2009-06-23 18:33:14

Thanks mmichelson!

Also, I forgot to note, I have the following enabled (not sure if these might make a difference in this case): MALLOC_DEBUG, DONT_OPTIMIZE, DEBUG_THREADS and DEBUG_CHANNEL_LOCKS
By: Mark Michelson (mmichelson) 2009-06-23 18:36:26

Those should have no effect on whether the deadlock (or infinite loop) occurs.
By: Mark Michelson (mmichelson) 2009-06-24 13:17:21

After a second look through the code, I still cannot see how the dialoglist could become looped. Still, an infinite loop is the only explanation that makes any sense given the lock output you have provided. What patches have you applied to chan_sip.c? At this point, the only thing I can think of that might be causing this is a patch added on.
By: Samy Kamkar (samyk) 2009-06-25 13:08:48

Mmichelson,

I've uploaded the diff between 1.6.0.10 and my version of chan_sip.c.

Also note, *nothing* in my configuration uses the SIPRemodeHeader function (though I doubt it would cause this issue in the first place).

Thanks
By: Samy Kamkar (samyk) 2009-06-25 13:09:49

You can ignore chan_dahdi.txt -- I thought it touched dialoglist but it touches iflist, so it shouldn't have any effect here.
By: Samy Kamkar (samyk) 2009-06-29 17:57:40

This happened again. This time I got a valid core dump and confirmed `dialoglist` is in fact an infinite loop (repeating at every 65 sip_pvt->next's)
By: Samy Kamkar (samyk) 2009-06-29 20:14:54

A thought of how this might happen:

What if one of the sip_pvt's in the linked list get free'd but doesn't get removed from the list (bug). Then sip_alloc is called and creates a new sip_pvt allocated at the SAME address as the previous one. It gets pushed to the beginning of dialoglist.

So we had:
dialoglist = a -> b -> c -> d -> NULL

The memory at 'c' gets freed but dialoglist doesn't get UNLINKed. We then do a sip_alloc which creates a new sip_pvt at 'c'. It then does:

// p is same memory address as c
p->next = dialoglist;
dialoglist = p;

You now have:
dialoglist = c -> b -> c -> b...
By: Samy Kamkar (samyk) 2009-06-29 20:53:49

One additional note, the infinite loop in `dialoglist` starts from the beginning (meaning `dialoglist` is repeated).

It COULD have been:
a -> b -> c -> d -> b -> c -> d -> b -> c -> d....

But in two instances of the loop, it's always looped back to 'a' (which I think could further be proof for my theory, but who knows...not me :)

In the two cores that I have, it's:
a -> b -> c -> d -> a -> b -> c -> d -> a...
By: Theo Belder (tbelder) 2009-12-09 08:20:23.000-0600

I have also deadlocks in do_monitor. Suddenly chan_sip isn't responding anymore.
I've attached a gdb backtrace and core show locks.
By: Theo Belder (tbelder) 2009-12-09 08:57:56.000-0600

My logfile of asterisk reports the following warnings:

[Dec 9 10:52:40] WARNING[20591] channel.c: Fixup failed on channel SIP/1121-0a4b8f80, strange things may happen.
[Dec 9 10:52:40] WARNING[20591] channel.c: Hangup failed! Strange things may happen!
[Dec 9 10:52:40] WARNING[20591] channel.c: Masquerade failed
[Dec 9 10:52:40] WARNING[20591] channel.c: Channel 'SIP/1121-0a4b8f80' may not have been hung up properly

At 10:53:15 my SIP provider reports an UNREACHABLE notice to me.
I've checked immediately the customer's site and chan_sip wasn't responding anymore.

Possible this has something to do with each other.
By: Nicolas Duteil (nduteil) 2010-04-19 08:03:08

Hi,
Anything new on this ticket ?
I also have the  "strange things may happen" problem mentioned above.
I use asterisk version 1.4.25

WARNING[11687] channel.c:3681 in ast_do_masquerade: Fixup failed on channel [Local,SIP/172.16.171.16:5060-082d87a8<MASQ>] (original = [SIP;SIP/172.16.171.16:5060-082d87a8]), strange things may happen.
WARNING[11687]: channel.c:3689 in ast_do_masquerade: Hangup failed!  Strange things may happen!
WARNING[11687]: channel.c:2044 in __ast_read: Failed to perform masquerade
WARNING[11687]: channel.c:1247 in ast_channel_free: Channel 'SIP/172.16.171.16:5060-082d87a8' may not have been hung up properly

After that, asterisk server freeze within 30s.

Result of core show locks :

=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 3077278640 (do_monitor           started at [16667] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 16519 do_monitor &iflock 0xb772a760 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 16531 do_monitor &sip->lock 0x82d87a8 (1)
=== -------------------------------------------------------------------
===
=== Thread ID: 3060448176 (pbx_thread           started at [ 2660] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 4673 sip_alloc &iflock 0xb772a760 (1)
=== --- ---> Locked Here: chan_sip.c line 16519 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: 3068693424 (pbx_thread           started at [ 2660] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 4673 sip_alloc &iflock 0xb772a760 (1)
=== --- ---> Locked Here: chan_sip.c line 16519 (do_monitor)
=== -------------------------------------------------------------------
===
=== Thread ID: 3064134576 (session_do           started at [ 2521] manager.c accept_thread())
=== ---> Lock #0 (manager.c): RDLOCK 2280 process_message &actionlock 0x8174040 (1)
=== -------------------------------------------------------------------
===
=== Thread ID: 3069676464 (pbx_thread           started at [ 2660] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 4673 sip_alloc &iflock 0xb772a760 (1)
=== --- ---> Locked Here: chan_sip.c line 16519 (do_monitor)
=== -------------------------------------------------------------------
===
=======================================================================


By: Russell Bryant (russell) 2011-07-27 13:33:23.403-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!