| 00:17.12 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:17.13 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 03:58.53 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.103) |
| 06:02.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:180d:5f02:297f:40fc) |
| 06:09.28 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:32.44 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.53) |
| 09:23.14 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.53) |
| 11:11.46 | *** join/#asterisk-dev pchero_work (~pchero@109.38.140.39) |
| 12:00.52 | *** join/#asterisk-dev scgm11_ (~scgm11@67.pool85-48-187.static.orange.es) |
| 12:22.22 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:58.49 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-dwayxarqgydehjix) |
| 13:58.49 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:06.09 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 15:55.34 | sahmed | Hello, One question regarding ao2_lock, If we need to do a lock on member of ast_sip_channel_pvt then should we lock the associate ast_channel before? |
| 15:58.11 | sahmed | If I am not understand wrong, this doc explained so, https://wiki.asterisk.org/wiki/display/AST/Locking+in+Asterisk |
| 16:02.02 | file | it depends what thread, but generally yes - the channel needs to be locked first |
| 16:08.26 | sahmed | In method cli_channelstats_print_body in cli_commands.c, The channel was Locked and Unlocked but an associated pvt->media->rtp has being locked beyond the channel locked unlocked. I guessed this could be a reason for a recent crash in our system. |
| 16:10.23 | file | it depends on what lock is supposed to protect it |
| 16:10.44 | file | it is most likely the channel lock |
| 16:19.50 | sahmed | <PROTECTED> |
| 16:20.42 | file | the RTP API takes care of the locking |
| 16:21.38 | sahmed | So, no need to care about the channel lock |
| 16:22.13 | file | the RTP API takes care of the locking on RTP instances |
| 16:22.36 | file | it does not take care of the RTP instance in pvt->media, whether that can go away, that kind of stuff |
| 16:22.44 | file | you'd need to confirm that holding the channel lock protects against that |
| 16:28.42 | sahmed | Actually, I have confusion on this, I guessed, it could be the scenario, the channelstats command and the channel cleanup may have some race situation. |
| 16:29.34 | sahmed | To eliminate this we bumped the rtp instance in a place, but that didn't work |
| 16:30.07 | file | did you examine the channel during the crash to determine its state, and the state of media and rtp? |
| 16:30.42 | sahmed | yes I can do that hopefully |
| 16:31.19 | sahmed | Can I share those here? |
| 16:32.03 | file | you can share backtraces, but that may not actually show what is going on, examining the state of things in gdb would then be needed |
| 16:37.11 | sahmed | Backtrace: https://codeshare.io/2WZ8o8 |
| 16:37.29 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.103) |
| 16:38.17 | file | yes, so the RTP instance is likely being destroyed or destroyed |
| 16:39.01 | file | so the channel lock may protect against that, I don't know if it will in this particular scenario/thread |
| 16:47.42 | seanbright | it's being destroyed or destroyed? that sounds bad |
| 17:04.30 | sahmed | @file Let me check this, and ill post all updates here... Thank you |
| 21:33.33 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-142-242.socal.res.rr.com) |
| 21:57.49 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 21:57.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |