| 02:55.56 | *** join/#asterisk-dev infobot (ibot@208.53.50.138) |
| 02:55.56 | *** topic/#asterisk-dev is 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 |
| 04:46.28 | *** join/#asterisk-dev joshelson (~joshelson@96-93-210-49-static.hfc.comcastbusiness.net) |
| 04:56.46 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-197-145.w92-139.abo.wanadoo.fr) |
| 06:55.25 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:12.05 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 07:30.34 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::10de) |
| 07:58.10 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:09.22 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:09.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:11.04 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:19.46 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:52.33 | *** join/#asterisk-dev tuxian_ (~tuxian@194.12.3.78) |
| 10:07.02 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 10:08.55 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 10:25.59 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:29.38 | *** join/#asterisk-dev ggo (25130a21@gateway/web/freenode/ip.37.19.10.33) |
| 10:37.55 | *** join/#asterisk-dev joshelson (~joshelson@l136.denver.dsl.forethought.net) |
| 10:46.15 | *** join/#asterisk-dev ggo (~quassel@37.19.10.33) |
| 10:48.32 | tsearle | @ggo told @cresl1n you went climbing yesterday, he got jealous |
| 10:48.49 | tsearle | he told me to say hi by the way |
| 11:38.44 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:37.49 | tsearle | good afternoon all! |
| 12:38.07 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 12:39.52 | *** join/#asterisk-dev ggo (~quassel@37.19.10.33) |
| 12:45.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:45.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:05.47 | cresl1n | waves |
| 13:06.28 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mfycleighnuctogv) |
| 13:06.28 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:12.22 | cresl1n | No way! |
| 13:12.31 | cresl1n | Richard Begg submitted a test suite test for overlap |
| 13:12.39 | cresl1n | good for him! |
| 13:12.42 | cresl1n | goes to check it out |
| 13:15.54 | file | indeedy |
| 13:17.37 | cresl1n | file: did you verify Josh Elson got his pjproject patch submitted upstream before +2'ing his review on gerrit? |
| 13:17.44 | file | yes |
| 13:17.45 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 13:17.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 13:18.29 | file | he posted on the ASTERISK issue with a link to the PJSIP commit and I verified they were the same |
| 13:21.09 | cresl1n | excellent |
| 13:21.10 | cresl1n | thanks |
| 13:21.20 | cresl1n | Good job Josh |
| 13:22.00 | cresl1n | On another note: Gerrit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| 13:22.07 | cresl1n | YOU FORGOT ME AGAIN. |
| 13:23.31 | file | you should channel this frustration into something else |
| 13:23.32 | file | like swimming |
| 13:27.00 | cresl1n | too early |
| 13:27.29 | cresl1n | On a totally separate note, is there a way to add someone as a reviewer to a review on their behalf? |
| 13:29.12 | file | click the person icon on the right of the Reviewers |
| 13:29.14 | file | type in name |
| 13:29.32 | file | select person, click add |
| 13:29.32 | file | dance |
| 13:29.54 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 13:33.58 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-zphluqdtejentvgc) |
| 13:33.58 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:35.13 | cresl1n | oooh |
| 13:35.21 | cresl1n | I wonder if using that power will piss some people off |
| 13:35.47 | file | I don't know what it actually... does... |
| 13:46.06 | *** join/#asterisk-dev Guest70_ (~textual@r186-52-239-224.dialup.adsl.anteldata.net.uy) |
| 13:48.17 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 13:48.50 | Guest70_ | @file should I cherry pick to 14 and master the review about CDR? sorry for the missformat |
| 13:49.04 | file | yes |
| 13:50.16 | Guest70_ | done |
| 14:02.26 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::7) |
| 14:06.07 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:06.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:17.15 | tzafrir | Still no Gerrit component for DAHDI? |
| 14:17.30 | tzafrir | Any reason I should not just post things on asterisk-dev? |
| 14:18.45 | tzafrir | (Or just commit and hope for the best) |
| 14:19.59 | tzafrir | cresl1n, what do you think? |
| 14:21.34 | tzafrir | (One reason not to use Gerrit: I have committed a patch set of 14 patches or so recently. I'm not sure Gerrit is the right tool to review long patch sets) |
| 14:23.32 | cresl1n | Are you talking about wanting to use gerrit for DAHDI, tzafrir? |
| 14:24.27 | tzafrir | Or whatever method of reviewing patches. |
| 14:24.47 | cresl1n | Good question |
| 14:24.54 | tzafrir | Right now I send them by mail to some people. |
| 14:25.04 | cresl1n | Although I'm responsible for the Asterisk project, I'm not responsible for DAHDI anymore |
| 14:25.40 | cresl1n | I can ask around though |
| 14:25.56 | tsearle | @cresl1n you can never escape DAHDI! |
| 14:26.09 | cresl1n | gerrit would be a nice way to review DAHDI patches though |
| 14:26.39 | cresl1n | tzafrir, for now, the -dev list is a decent place to start |
| 14:27.07 | tzafrir | Nobody minds the sacred copyrights? |
| 14:27.39 | cresl1n | I think that's always a concern |
| 14:27.45 | cresl1n | and goes with the territory |
| 14:28.23 | tzafrir | OK. I'll post it there. |
| 14:36.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-uxsvnsaeqtkuqbah) |
| 14:36.15 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:39.12 | *** join/#asterisk-dev joshelson (~joshelson@216.241.45.82) |
| 14:53.52 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rtjvnbwzhupaqqfj) |
| 14:53.52 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:55.17 | *** join/#asterisk-dev DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 14:55.17 | *** mode/#asterisk-dev [+o DivideBy0x0] by ChanServ |
| 14:55.22 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-nddldjragzptnnes) |
| 14:55.22 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:58.09 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-pgdardjrarhjiukj) |
| 14:58.09 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:17.48 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 15:22.10 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 15:55.33 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-wjyhrifbhnbvwroh) |
| 15:55.33 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:07.27 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 16:35.25 | *** join/#asterisk-dev tuxian_ (~tuxian@194.12.3.78) |
| 16:38.47 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 16:43.38 | *** join/#asterisk-dev tuxian (~tuxian@80.229.252.17) |
| 17:15.10 | *** join/#asterisk-dev samoied (~samoied@186.222.23.155) |
| 17:54.45 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ottddtvrhglvdwnt) |
| 17:54.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:59.00 | rmudgett | file: putnopvut: RE: https://issues.asterisk.org/jira/browse/ASTERISK-26835 The https://issues.asterisk.org/jira/secure/attachment/55104/backtrace_core.uc62-2017-03-02T11-47-33%2B0100.txt backtrace shows what is happening. |
| 17:59.18 | rmudgett | The crashing thread 1 is interacting with thread 271 |
| 17:59.39 | putnopvut | You mean 270? |
| 18:00.15 | rmudgett | yes that thread. :) |
| 18:00.34 | putnopvut | Yeah, looks like the channel thread and the session serializer thread are at odds. |
| 18:01.09 | rmudgett | The only way to fix is to add a lock without reworking how the threading does things. |
| 18:02.01 | rmudgett | That's going to get nasty. |
| 18:04.26 | rmudgett | Question is what should I protect? The whole structure or only the address structures which the local_addr_str relies? |
| 18:04.51 | putnopvut | I'm actually having trouble figuring out what structure is the problematic one here. |
| 18:05.17 | putnopvut | I need to check out the specific version where the crash occurred so I can have the proper line numbers. |
| 18:05.40 | rmudgett | rtp->rtcp->local_addr_str is the problem pointer causing the crash. |
| 18:05.52 | rmudgett | Version is 13.14.0 |
| 18:06.21 | putnopvut | Okay, so that's being freed by thread 1. I'm having trouble seeing what thread 270 has done wrong though. |
| 18:07.08 | putnopvut | Was it because it called ast_rtp_instance_remote_address_set()? |
| 18:07.11 | rmudgett | Right before it calls set_caps() it changed rtp->rtcp->local_addr_str |
| 18:07.18 | rmudgett | yes |
| 18:08.09 | putnopvut | Gotcha |
| 18:08.49 | putnopvut | Yeah, that's just a straight up race on a critical section, and I agree that a lock is probably what's necessary. The ast_rtp has a lock. Would there be any potential repercussions to using that lock in the remote_address_set() function? |
| 18:09.54 | rmudgett | The lock would need to be used consistently to protect access to that string. |
| 18:12.32 | rmudgett | Currently that lock is only used to protect rtp->trun_state and thread sync |
| 18:12.55 | rmudgett | s/trun/turn/ |
| 18:15.50 | rmudgett | The rtcp struct seems to be accessed only as part of the rtp struct so it looks like the rtp lock could be used. |
| 18:17.24 | file | the channel lock is supposed to protect it afaik |
| 18:18.54 | rmudgett | That lock is quite removed from rtp. |
| 18:19.32 | file | yes, RTP never had a lock originally - it was just needed for some ICE stuff |
| 18:20.22 | rmudgett | I could certainly check the rtp API calls to see if they are normally protected by the channel lock |
| 18:21.29 | *** join/#asterisk-dev tuxd00d (~tuxd00d@66.23.136.140) |
| 18:21.30 | file | read and write certainly is |
| 18:22.39 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 18:25.12 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ahgbxvcouphtabmx) |
| 18:25.12 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:34.38 | cresl1n | That jives with my memory |
| 18:36.42 | file | the locking of RTP predates my time, it originates from the young cresl1n era |
| 18:37.02 | cresl1n | most things were assumed locked by the channel lock by default |
| 18:37.10 | cresl1n | at the very least |
| 18:37.17 | cresl1n | and the channel private if not |
| 18:37.21 | file | cresl1n: the good ol' days |
| 18:37.43 | cresl1n | The days keep getting better :-) |
| 19:11.16 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 19:11.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:13.00 | *** join/#asterisk-dev tuxd00d (~tuxd00d@66.23.136.140) |
| 19:36.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00b925f7e5df7529cd.ipv6.abo.wanadoo.fr) |
| 19:49.59 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 19:49.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:26.13 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 20:26.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:28.05 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 20:28.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:44.03 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 21:07.46 | putnopvut | I want to have a discussion about SDP logic if anyone is interested. |
| 21:08.18 | putnopvut | I've been working on the concept of merging capabilities, and I've realized I'm not 100% sure what to do in certain circumstances. |
| 21:08.52 | putnopvut | If we are offering an SDP, and we receive an answer, it's pretty simple. The remote *should* have the same number of streams as we offered. |
| 21:09.13 | putnopvut | But if we are receiving an SDP offer, there's no guarantee that the streams offered by the remote party are going to align with what our local capabilities are. |
| 21:09.39 | putnopvut | We might have a video stream and two audio streams as our local capabilities, but we might get offered a single audio and a single video stream. |
| 21:10.07 | putnopvut | So would the appropriate thing be to match the first stream of each type with each other? |
| 21:10.27 | file | I think that's the best you can do |
| 21:11.04 | putnopvut | Okay, cool. |
| 21:11.35 | file | later whatever is needing more or to change things can do a topology change request to try to get it to where it needs to be |
| 21:13.13 | file | it'd be niiiiiice if we could match it, if it's the initial... |
| 21:13.28 | file | but, pros/cons to that |
| 21:15.30 | file | wanders off |
| 21:21.05 | cresl1n | sends file cookies |
| 21:27.46 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 21:31.11 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 21:41.12 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:41.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:02.40 | cresl1n | okies, gtg, dad time |
| 22:56.14 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-uxsvnsaeqtkuqbah) |
| 23:29.44 | *** join/#asterisk-dev joshelson (~joshelson@162.246.45.197) |