| 00:33.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.147) |
| 01:00.51 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:25.41 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 01:25.41 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:34.07 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.116) |
| 01:56.34 | *** join/#asterisk-dev suneye (~atcmmi@116.25.196.6) |
| 02:05.25 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 02:34.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.114) |
| 03:05.53 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:07.50 | *** join/#asterisk-dev calidosinho (~santiago@181.132.97.244) |
| 03:35.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.36) |
| 03:59.40 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 04:03.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 04:06.44 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:36.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.125) |
| 04:41.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.125) |
| 05:07.21 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:09.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.125) |
| 05:26.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.117) |
| 05:29.47 | *** join/#asterisk-dev micols (~t@81.161.188.225) |
| 05:41.48 | *** join/#asterisk-dev suneye (~atcmmi@116.25.196.6) |
| 06:26.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.119) |
| 06:41.23 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 06:47.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.124) |
| 06:50.47 | *** join/#asterisk-dev suneye (~atcmmi@121.34.40.105) |
| 07:01.35 | *** join/#asterisk-dev micols (~t@shell1.rlogin.dk) |
| 07:04.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.124) |
| 07:08.14 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:55.10 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 08:06.20 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 08:31.56 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5834:9913:b1d8:b92a) |
| 08:38.47 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:45.08 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:45.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:45.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.167.197) |
| 08:45.27 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 09:44.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.167.197) |
| 09:52.04 | *** join/#asterisk-dev suneye (~atcmmi@121.34.40.105) |
| 10:53.08 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:53.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:59.53 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 11:02.55 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 11:46.35 | *** join/#asterisk-dev Greenlight (wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginm.net) |
| 11:49.57 | *** join/#asterisk-dev anonymouz666 (~anonymouz@179.236.141.86) |
| 12:14.07 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.167.197) |
| 12:14.45 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:14.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:26.12 | *** join/#asterisk-dev suneye (~atcmmi@116.25.196.6) |
| 12:35.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.167.197) |
| 12:36.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.68.167.197) |
| 12:40.29 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 13:13.42 | *** join/#asterisk-dev micols (~t@shell1.rlogin.dk) |
| 13:16.18 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:19.43 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 13:29.49 | oej | Afternoon folks |
| 13:31.09 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 13:31.46 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:33.12 | file | moo |
| 13:40.25 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:48.55 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:02.38 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yrdwgpakzywpxjgz) |
| 14:04.27 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:14.31 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:14.31 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:16.09 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 14:16.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:16.47 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:16.47 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:35.17 | *** join/#asterisk-dev micols (~t@shell1.rlogin.dk) |
| 14:40.57 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:40.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:07.17 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:07.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:08.29 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-zdupgppahwbehcjj) |
| 15:08.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:21.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.65) |
| 15:35.20 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 15:40.25 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jqymatdwcfydlpvo) |
| 15:41.56 | sruffell | datachomper, tzafrir: I went ahead and pushed the two PDE_DATA commits to a new 2.7.y branch: http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=shortlog;h=refs/heads/2.7.y |
| 15:42.10 | sruffell | I think it should be ok to release a 2.7.0.2. |
| 15:46.01 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:46.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:46.47 | sruffell | (We might really want to look into seeing if we can either replace or fix the URLs that gitweb produce to something a little more friendly) |
| 15:49.44 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:49.44 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:51.02 | datachomper | okay |
| 15:51.11 | datachomper | releasing 2.7.0.2 |
| 16:07.36 | tzafrir | datachomper, btw: what do you use to build the release tarball? |
| 16:07.52 | datachomper | super secret sauce! |
| 16:08.16 | datachomper | tzafrir: I just have a simple build script in python |
| 16:12.31 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 16:15.26 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:15.39 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:37.06 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 17:42.39 | *** join/#asterisk-dev sluvitz (~sluvitz@fl-71-3-159-123.dyn.embarqhsd.net) |
| 17:45.31 | file | leedm777, if I changed the topic of a subscription... how much would the world explode? |
| 17:47.41 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-oykrczjghoqdncjq) |
| 17:54.36 | opticron | file, instead of unsubscribing and resubscribing? |
| 17:54.52 | file | opticron, that requires the consumer to do it |
| 17:56.24 | *** join/#asterisk-dev xytis (~xytis@5.20.223.100) |
| 17:57.12 | opticron | so you want to change the topic a subscription is subscribed to without claiming ownership of the subscribe/unsubscribe cycle and without triggering the cleanup that occurs upon unsubscription? |
| 17:58.19 | file | I need to either change the topic something is subscribed to, or have a mechanism that allows them to subscribe to a topic I provide and block until complete |
| 18:01.25 | opticron | the first option isn't feasible without being able to look into both the topic and the subscription and manipulate their innards |
| 18:03.15 | opticron | you could go with option 2 and define a message that tells subscribers to unsubscribe from their subscriptions |
| 18:04.27 | opticron | hmmm...and I think subscription objects are supposed to be immutable as well |
| 18:04.43 | opticron | though you'd have to check with leedm777 on that |
| 18:06.13 | file | yeah... option 2 was what I came up with yesterday |
| 18:07.56 | opticron | subscription masquerades! |
| 18:08.11 | file | not exactly. |
| 18:31.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.77) |
| 19:02.16 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-ydsjubbzmemxyrro) |
| 19:04.59 | file | putnopvut / jrose_atDigium: I have... a thought |
| 19:05.24 | putnopvut | is it about electric sheep? |
| 19:05.27 | file | fixup in pjsip is a synchronous task, which means if something is already doing a masquerade in there... it'll... be sad |
| 19:06.16 | putnopvut | Oh...OH! |
| 19:06.19 | putnopvut | Yeah, that's a problem. |
| 19:06.25 | putnopvut | Well, easy fix though |
| 19:06.35 | putnopvut | There's a function in res_pjsip.c where you can test if you're a servant thread. |
| 19:06.53 | putnopvut | If you are, then just call fixup() directly, otherwise push a synchronous task. |
| 19:07.06 | file | oh, yes |
| 19:07.10 | file | well, maybe |
| 19:07.34 | file | I withhold a confirmation of that until it is tested :P |
| 19:07.37 | putnopvut | In this particular case, it should work. |
| 19:07.50 | putnopvut | Because the thread that is stuck in the fixup is run from a servant thread. |
| 19:08.09 | putnopvut | Wait, I have it backwards |
| 19:08.11 | putnopvut | That won't work. |
| 19:08.24 | putnopvut | The thread stuck in the fixup is a pbx thread. |
| 19:08.29 | file | I don't know if it... will... or not |
| 19:08.43 | putnopvut | It can't push the synchronous task because the other masquerade is occurring in a servant thread. |
| 19:08.54 | putnopvut | holy barfing cows. |
| 19:09.17 | putnopvut | So yeah, not quite as simple. |
| 19:09.48 | file | I'd like to see jrose's gdb for confirmation of the threads |
| 19:10.07 | putnopvut | Well you can see from the core show locks where the threads started. |
| 19:10.21 | putnopvut | The one that's holding the locks (and should thus be in the fixup) is a pbx thread. |
| 19:10.25 | putnopvut | The other is a threadpool thread. |
| 19:10.29 | file | aye |
| 19:10.31 | jrose_atDigium | I haven't run gdb on it yet. I can at least confirm that ast_sip_push_task_synchronous in the chan_pjsip function isn't completing though. |
| 19:10.53 | jrose_atDigium | *fixup function |
| 19:11.14 | file | putnopvut, I think your suggestion is still needed... |
| 19:11.40 | jrose_atDigium | And yes, it's the PBX thread that is doing the fixup. |
| 19:11.41 | putnopvut | file: yeah, but it may just be that we need to *always* just do the fixup in-line instead of sometimes pushing the task. |
| 19:11.58 | putnopvut | Not based on whether the fixup is occurring in a SIP servant thread. |
| 19:12.09 | file | we'd have to lock around our channel usage |
| 19:12.19 | putnopvut | file: would we? |
| 19:12.25 | putnopvut | The masquerade should already have the channels locked |
| 19:12.35 | putnopvut | And fixup is called only from masquerades. |
| 19:12.51 | file | it's a pointer on the session, something else could still access that if you muck with it outside of the serializer |
| 19:13.17 | file | and there is no guarantee you will be in a servant thread |
| 19:13.42 | putnopvut | COrrect, this is a case-in-point. The fixup is occurring both in a pbx thread and a servant thread. |
| 19:14.01 | file | aye |
| 19:14.01 | putnopvut | Right, it's the session that needs to be protected, not the channel. |
| 19:14.05 | file | yes |
| 19:14.25 | putnopvut | so, here's a crazy question. |
| 19:14.43 | putnopvut | What would happen if the fixup weren't synchronous? |
| 19:14.54 | file | WELL, it may or may not work |
| 19:15.04 | file | we have a ref to the channel so the object itself is still sound |
| 19:15.25 | file | contents wise... I don't... know... |
| 19:15.46 | file | nothing has ever attempted that |
| 19:16.05 | putnopvut | yeah, I know what you mean. Uncharted territory. |
| 19:16.22 | file | I think we should try both, if only to see what happens |
| 19:16.36 | putnopvut | Heh, okay. |
| 19:17.18 | putnopvut | The big thing I could see occurring that would be bad would be if an operation occurs on the wrong channel. Except I don't think that would happen since all tasks on the session should be happening in the serializer. |
| 19:17.26 | file | aye |
| 19:17.39 | file | I *think* your original idea will resolve it nicely |
| 19:17.52 | putnopvut | I don't think it will though. |
| 19:17.57 | file | the masquerade code already handles the case of another thread doing the masquerade |
| 19:19.33 | file | why not? |
| 19:19.41 | putnopvut | Okay, let's see if I can explain. |
| 19:20.07 | putnopvut | So in the core show locks code that jrose_atDigium posted, the pbx thread locks the channels lock, and the individual channels, and calls into the fixup code. |
| 19:20.32 | putnopvut | Meanwhile, the serializer itself is attempting to perform a masquerade, but it can't lock the channels lock because it's already held by the pbx thread. |
| 19:20.50 | file | aha, yeah |
| 19:20.52 | putnopvut | The fixup pushes a synchronous task, but it won't run because a task ahead of it is stuck trying to lock the channels lock. |
| 19:21.07 | putnopvut | So the thread doing the fixup in this case is not a servant thread, so the "fix" won't work. |
| 19:21.12 | putnopvut | I think like you said, we need both. |
| 19:21.34 | file | aye |
| 19:21.58 | file | although if it's non-synchronous it won't block, so having it as a task is still fine... just not as immediate as it could be |
| 19:22.18 | putnopvut | Yeah, it's probably fine to unconditionally push as an asynchronous task. |
| 19:23.06 | putnopvut | SO jrose_atDigium, quick fix idea from us is to change the ast_sip_push_task_synchrnonous() call in chan_pjsip_fixup() in chan_pjsip.c to be ast_sip_push_task() instead. See if that resolves the issue for you. |
| 19:23.37 | file | jrose_atDigium, make sure your reference counting is sane |
| 19:23.48 | putnopvut | Yes, that too :) |
| 19:25.13 | jrose_atDigium | Well, without changing any references that yielded a segfault. I'm just going to go ahead and assume now that's because something got dissolved before the asynchronous function executed. |
| 19:25.41 | jrose_atDigium | oh |
| 19:25.44 | jrose_atDigium | even sillier than that |
| 19:25.52 | jrose_atDigium | fixup_data isn't alloced. |
| 19:26.33 | file | of course not, it was a synchronous task before ^_^ |
| 19:26.35 | putnopvut | Yep. You'll need to alloc the fixup_data and bump refs on the session and channel. |
| 19:26.43 | jrose_atDigium | easy enough |
| 19:26.47 | putnopvut | Yep |
| 19:29.26 | jrose_atDigium | Good news everyone. I haven't added the cleanup yet, but it fixes the problem. |
| 19:30.12 | file | the question you should be asking yourself is: "what sort of repercussions does this completely untested and never been done before approach for the fixup callback have?" |
| 19:33.48 | jrose_atDigium | Well, I imagine in this case it will just change the RTP media paths slightly later. I'm not sure if there is any danger in not immediately fixing the media paths... like if the channels vanish and we are still trying to send media to them or something. |
| 19:34.58 | jrose_atDigium | oh wait |
| 19:35.12 | jrose_atDigium | It sets the channel that owns the RTP instance... |
| 19:35.17 | file | putnopvut, I think he just realized the implications |
| 19:35.31 | jrose_atDigium | If a channel breaks down while it owns an RTP instance... |
| 19:35.42 | jrose_atDigium | I wonder if that couldn't kill the RTP instance as well |
| 19:36.07 | file | it should be fine |
| 19:36.26 | file | what this impacts is API invocations from inside PJSIP to Asterisk |
| 19:37.29 | file | that is what worries me since if stuff is in-flight ahead of your fixup task and you give ast_* stuff a channel that is technically a zombie.... it might go insane |
| 19:44.36 | jrose_atDigium | Hmmm, adding cleanup to the fix_data seems to have turned it rather segfaulty. |
| 19:45.40 | jrose_atDigium | oh wait, I might have just done something a little backwards :< |
| 19:49.08 | jrose_atDigium | and confirmed. |
| 19:50.22 | putnopvut | you have the power to scare me quite easily :) |
| 19:52.16 | file | putnopvut, you scare easily |
| 19:52.26 | putnopvut | EEK! |
| 20:48.03 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 20:57.10 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 21:05.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.65) |
| 21:14.03 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:14.04 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:18.03 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 21:48.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.65) |
| 21:59.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:07.30 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.65) |
| 22:15.59 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:15.59 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:54.30 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 22:54.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:50.20 | *** join/#asterisk-dev geilt (~geilt@184.164.168.127) |
| 23:57.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.68) |