Summary: | ASTERISK-16395: tcp-tls deadlock | ||
Reporter: | Mark Murawski (kobaz) | Labels: | |
Date Opened: | 2010-07-20 13:15:56 | Date Closed: | 2010-08-10 20:55:52 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/TCP-TLS |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | This is all the info I have so far... I've seen this fairly often on 1.6.2. Not sure how to reproduce just yet. -- Executing [250@trunkhandler_incoming-branch:1] Gosub("SIP/branch-sip-00000000", "Login,s,1(1)") in new stack -- Executing [s@Login:1] Set("SIP/branch-sip-00000000", "LOCAL(tenant_id)=1") in new stack -- Executing [s@Login:2] Ringing("SIP/branch-sip-00000000", "") in new stack -- Executing [s@Login:3] Set("SIP/branch-sip-00000000", "ARGS="action=Login,tenant_id=1"") in new stack -- Executing [s@Login:4] AGI("SIP/branch-sip-00000000", "login.pl") in new stack -- Launched AGI Script /var/lib/asterisk/agi-bin.login.pl == Using SIP RTP CoS mark 5 -- Executing [250@trunkhandler_incoming-branch:1] Gosub("SIP/branch-sip-00000001", "Login,s,1(1)") in new stack -- Executing [s@Login:1] Set("SIP/branch-sip-00000001", "LOCAL(tenant_id)=1") in new stack -- Executing [s@Login:2] Ringing("SIP/branch-sip-00000001", "") in new stack -- Executing [s@Login:3] Set("SIP/branch-sip-00000001", "ARGS="action=Login,tenant_id=1"") in new stack -- Executing [s@Login:4] AGI("SIP/branch-sip-00000001", "login.pl") in new stack -- Launched AGI Script /var/lib/asterisk/agi-bin/login.pl [Jul 20 14:06:40] ERROR[15962]: utils.c:529 lock_info_destroy: Thread 'handle_tcptls_connection started at [ 276] tcptls.c ast_tcptls_server_root()' still has a lock! - '&c->lock_dont_use' (0xb38fd510) from 'channel_find_locked' in channel.c:1244! [Jul 20 14:06:40] ERROR[15962]: utils.c:529 lock_info_destroy: Thread 'handle_tcptls_connection started at [ 276] tcptls.c ast_tcptls_server_root()' still has a lock! - '&c->lock_dont_use' (0xb03e84b0) from 'channel_find_locked' in channel.c:1244! | ||
Comments: | By: Mark Murawski (kobaz) 2010-07-20 13:16:27 After seeing that message, asterisk is completely locked up and cannot receive calls or list channels. By: Mark Murawski (kobaz) 2010-07-20 13:28:08 14:24 <@russellb> manager would be more likely related to this particular error 14:24 <@russellb> since all kinds of manager actions do async channel lookups 14:24 <@putnopvut> yep. And unfortunately that doesn't really narrow the scope of the search for the problem either since manager actions are registered all over the place. 14:26 <@russellb> i'll give you a hint as to what you're looking for 14:26 <@russellb> look at action_hangup() in main/manager.c 14:27 <@russellb> it calls ast_get_channel_by_name_locked() 14:27 <@russellb> later calls ast_channel_unlock() 14:27 <@russellb> there is something that is doing a channel lookup like that, and forgetting to unlock the channel most likely By: Paul Belanger (pabelanger) 2010-07-20 14:30:10 Guess we would need a backtrace (deadlock) to triage the issue. By: Mark Murawski (kobaz) 2010-07-26 10:19:17 I've added debugging to the channel locks. Hopefully I'll hit the bug again soon. By: Mark Murawski (kobaz) 2010-08-09 13:52:28 This can be closed... I had a bad merge of my own code. Not an asterisk bug. |