| 00:11.44 | gtjoseph | yeah |
| 00:11.45 | coreyfarrell | yes. the profiling is deceptive because that's the first function to read from the memory segment holding the object, so cache misses are concentrated to that function. |
| 00:45.22 | *** join/#asterisk-dev ulexus (~ulexus@68.143.200.66.nw.nuvox.net) |
| 04:57.48 | *** join/#asterisk-dev ulexus (~ulexus@68.143.200.66.nw.nuvox.net) |
| 06:06.57 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 06:33.05 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 06:51.25 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:52.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:10.38 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 07:22.03 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:22.03 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:55.30 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:43.48 | *** join/#asterisk-dev hajekd (~hajekd@212.24.153.186) |
| 12:14.45 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-efrxwmxytnxwrieo) |
| 12:14.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:16.58 | tzafrir | res_rtp_asterisk.c . It seems to have an optional dependency on openssl. Does this mean in needs to have '<use type="external">openssl</use>'? |
| 12:18.20 | tzafrir | And likewise main/tcptls.c ? |
| 12:19.19 | gtjoseph | probably would be a good idea |
| 12:53.55 | tzafrir | Done |
| 13:17.17 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pqwftqrclkbmqwqu) |
| 13:17.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:31.35 | seanbright | fyi - probably won't be able to do any profiling today to test the pjsip_tpmgr_find_local_addr2 change we discussed last night |
| 13:31.38 | seanbright | hopefully tomorrow |
| 13:32.00 | gtjoseph | NNNNOOOOOOO! I can't wait that long. |
| 13:32.57 | seanbright | well, i think intuitively we know it will be an improvement. how much of an improvement is the question. |
| 13:36.11 | seanbright | jira login still borked? |
| 13:36.20 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:36.20 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:36.26 | gtjoseph | shouldn't be. wasn't as of about an hour ago |
| 13:36.43 | seanbright | ah, good deal. i'm in. |
| 13:36.50 | gtjoseph | whew |
| 13:40.52 | seanbright | heh. you can rest easy. |
| 13:42.53 | file | REST easy. |
| 13:51.08 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-sawbppzxhtdhpald) |
| 13:51.08 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 13:58.33 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-sapmhbshdljmbsqx) |
| 13:58.34 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:02.57 | seanbright | is it possible that i lost some jira privileges during the problem yesterday? |
| 14:03.05 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 14:03.23 | gtjoseph | don't think so. what's missing? |
| 14:03.51 | seanbright | how do i assign a bug to someone? |
| 14:04.27 | gtjoseph | just click the current assignee |
| 14:04.38 | seanbright | not clickable for me |
| 14:04.41 | seanbright | https://issues.asterisk.org/jira/browse/ASTERISK-27312 |
| 14:04.59 | seanbright | maybe it's because of the current state of the issue? |
| 14:05.16 | gtjoseph | If you just hover over it does a pencil icon show up? |
| 14:05.23 | seanbright | no |
| 14:05.28 | gtjoseph | let me look at permissions |
| 14:05.34 | gtjoseph | cound you do it before? |
| 14:05.37 | file | sighs |
| 14:05.47 | seanbright | i'm pretty sure |
| 14:06.07 | gtjoseph | do you have the "assign to me" link? |
| 14:06.17 | seanbright | no |
| 14:06.24 | gtjoseph | oy |
| 14:06.46 | gtjoseph | while i'm looking, try logging out, clearing cache and cookies for the site then log in again. |
| 14:07.17 | file | I think permissions are just screwed up after yesterday |
| 14:07.46 | gtjoseph | maybe |
| 14:07.58 | gtjoseph | heh, seanbright your license id is 5060 :) |
| 14:08.00 | file | first rmudgett, now seanbright |
| 14:08.08 | seanbright | gtjoseph: NICE |
| 14:08.33 | seanbright | gtjoseph: cleared cache and cookies for all asterisk.org domains - still nothing |
| 14:08.46 | gtjoseph | yeah ok. |
| 14:13.34 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:13.34 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:15.11 | gtjoseph | seanbright: try logging out, clearing cache and cookies for the site then log in again. |
| 14:15.41 | seanbright | i skipped the cache clearing and just tried the logout/login |
| 14:15.42 | seanbright | and that worked |
| 14:15.49 | gtjoseph | cool |
| 14:15.55 | seanbright | thank you |
| 14:16.45 | file | I foresee us having to clean things up for... |
| 14:16.46 | file | awhile |
| 14:16.53 | gtjoseph | sigh |
| 14:17.02 | file | gtjoseph: +1 |
| 14:21.29 | seanbright | gtjoseph: assign to me not there? |
| 14:21.41 | gtjoseph | gimme a sec |
| 14:21.47 | gtjoseph | you're missing from a few other groups |
| 14:21.51 | seanbright | typical |
| 14:21.56 | seanbright | just put me in the same groups as digium |
| 14:22.01 | seanbright | i'm honorary digium intern |
| 14:22.06 | seanbright | taking bford's place |
| 14:22.19 | gtjoseph | i'll get right on that |
| 14:22.22 | seanbright | heh |
| 14:22.28 | seanbright | i don't believe you |
| 14:22.48 | file | our elevated privileges don't really get you much tbh |
| 14:22.55 | seanbright | i was kidding |
| 14:23.01 | file | dare I say, nothing? over what you already have |
| 14:23.05 | seanbright | i don't need that level of responsibility |
| 14:23.10 | seanbright | i need SWP access |
| 14:23.19 | seanbright | chop chop |
| 14:23.21 | file | Permission Denied. |
| 14:23.49 | seanbright | do you support digest auth? a8b9ff9edd9ca9 |
| 14:23.49 | gtjoseph | there's a group called "Former Developers" so watch out. |
| 14:23.54 | seanbright | lulz |
| 14:24.30 | gtjoseph | ok, do the logout/login thing again |
| 14:24.52 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fagwzkwdvlbdholc) |
| 14:24.52 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:25.01 | seanbright | gtjoseph: perfect |
| 14:25.03 | seanbright | as usual |
| 14:25.07 | gtjoseph | heh |
| 14:30.48 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:30.48 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:36.05 | wdoekes | FYI: not that I need them, but I also have fewer jira perms than before |
| 14:37.16 | gtjoseph | wdoekes: i'll look in a sec |
| 14:37.52 | wdoekes | take your time :) |
| 14:38.37 | gtjoseph | i'm dealing with that dang rmudgett now |
| 15:01.37 | *** join/#asterisk-dev dtascom (~dtascom@static-47-180-162-26.lsan.ca.frontiernet.net) |
| 15:10.28 | *** join/#asterisk-dev hajekd (~hajekd@212.24.153.186) |
| 15:54.57 | *** join/#asterisk-dev hajekd (~hajekd@81.90.251.91) |
| 16:07.26 | coreyfarrell | newtonr: is there a way to ask JIRA to show all PJSIP bugs? IE chan_pjsip plus all the resource modules? I mean other than any user who wants that list having a filter including all those categories.. |
| 16:08.02 | file | text ~ pjsip AND status != closed gets you a bit of the way |
| 16:12.33 | coreyfarrell | hmm that shows 226 bugs where searching by unclosed bugs in the categories only gives 118. |
| 16:12.58 | file | it'll also catch references in issues, even if it's not strictly a PJSIP issue but if they mentioned it |
| 16:13.03 | file | so it's not accurate, but it finds more |
| 16:13.12 | file | it's where I start when I'm searchin' |
| 16:16.58 | coreyfarrell | cool thanks |
| 16:25.27 | rmudgett | kharwell: Replied to your comment on the raii_var review. |
| 16:26.46 | seanbright | coreyfarrell: fixed the jira fuck up |
| 16:26.48 | seanbright | sorry about that |
| 16:28.31 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 16:28.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d001522d8b7a8fbfb8d.ipv6.abo.wanadoo.fr) |
| 16:28.38 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 16:29.20 | coreyfarrell | seanbright: it's cool, thanks for taking the time to setup the feature tracker bug. |
| 17:05.50 | coreyfarrell | cresl1n: so is there going to be a final standard release of 14 or is it already done? I ask since a few reviews are still open against 14. |
| 17:07.50 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 17:12.20 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.170) |
| 17:13.56 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-jndfsamhasthnviy) |
| 17:13.56 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:20.23 | rmudgett | There needs to be a final normal v14 release since there has been quite an accumulation of changes since the last release. |
| 17:21.01 | rmudgett | Many of those changes were added before the Sept 26 date. |
| 18:01.21 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:01.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:01.29 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-obmmzcjqrxyrxeja) |
| 18:01.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:01.34 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-mqekebbpccqjwyhk) |
| 18:01.34 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 18:05.18 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 18:05.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:06.55 | seanbright | T.140 supported by res_pjsip? |
| 18:07.46 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-afchedcdhapzwygl) |
| 18:07.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:08.00 | file | seanbright: no. |
| 18:13.17 | seanbright | k |
| 18:16.35 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qwhhavencodfcvpg) |
| 18:16.35 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 18:20.59 | cresl1n | coreyfarrell: Let's cut a final 14 release |
| 18:21.02 | cresl1n | I think that's a great idea |
| 18:26.58 | coreyfarrell | sounds good to me |
| 18:36.55 | coreyfarrell | does digium have a tool they use to mass close stale tickets with the message saying to try against a new version? half the open tickets in JIRA were last modified before Asterisk 13 was released, many of them long before Asterisk 13. |
| 18:37.50 | file | there is no tool, but there is a "Canned Response" thing in JIRA |
| 18:37.53 | file | that adds a comment with the text |
| 18:42.49 | coreyfarrell | any objection to me closing some of the stale chan_sip bugs with that canned response? would I set resolution to "Suspended"? |
| 18:44.32 | cresl1n | At one point, we were going to do a systematic cleaning of the bug tracker |
| 18:44.56 | cresl1n | start closing everything that's against a version of Asterisk that doesn't have bugfix support anymore |
| 18:45.02 | cresl1n | ponders |
| 18:45.11 | cresl1n | coreyfarrell: we missed you at Astricon |
| 18:46.48 | coreyfarrell | hopefully I'll be able to make the next one or at least the next one on the East coast. |
| 18:56.53 | seanbright | coreyfarrell: i'll need you to start smoking again though |
| 18:56.57 | seanbright | hope that's cool |
| 18:57.56 | coreyfarrell | I can still hang out, not going to start smoking again :) |
| 18:59.22 | seanbright | UGH |
| 18:59.33 | seanbright | i can never count on you when it MATTERS |
| 19:22.17 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 19:22.18 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:23.04 | coreyfarrell | when I need to move all entries of an AST_LIST_HEAD_NOLOCK to a new list, AST_LIST_APPEND_LIST is the correct macro to use after initializing the new list? |
| 19:25.15 | coreyfarrell | or should I just copy the list head to the new head then use AST_LIST_HEAD_SET_NOLOCK to clear the old list? |
| 19:51.13 | rmudgett | The copy head and re-init the old list may be more descriptive of the intent. There aren't many cases where it is done. However, there is a place in __ast_queue_frame() that appears to be using the append list approach. |
| 19:53.33 | coreyfarrell | I'll try that and re-test. |
| 19:57.12 | coreyfarrell | rmudgett: the change I'm making to the weakproxy locking means that it will be possible for ao2_weakproxy_unsubscribe to return 0 (callback not found) before the callback is run in another thread. |
| 19:57.35 | coreyfarrell | do you see that as a problem? obviously I'm adding a note to the doxygen for ao2_weakproxy_unsubscribe. |
| 20:01.09 | rmudgett | That was something I considered when thinking of calling it while the proxy is unlocked. It does make sense since the real object just died. The proxy object is then free to be reused if anyone ever cares to reuse it. Any subscriptions were for the old real object so they could automatically be unsubscribed. |
| 20:04.10 | Demon_VoIP | file, do you have time to look sip debug of one call? The reason: oneway audio with "asymmetric_rtp_codec=yes", origination with two Local/ legs? used simple_bridge. debug: [2017-10-10 22:44:06] DEBUG[19618][C-0000000b] translate.c: Sample size different 960 vs 160 |
| 20:04.54 | file | if you provide info someone here may be able to provide info |
| 20:05.07 | Demon_VoIP | https://pastebin.com/dTxUQS4Y |
| 20:05.33 | Demon_VoIP | interesting begins from line 1010: [2017-10-10 22:44:06] DEBUG[19674][C-0000000b] audiohook.c: Read factory 0x7fd3e0004e28 and write factory 0x7fd3e0005868 both fail to provide 160 samples |
| 20:11.36 | Demon_VoIP | sorry, call starts from line 114. Asterisk segfaulted and callid starts with same id :( that's why 1-114 line with same callid - other call. |
| 20:14.51 | coreyfarrell | rmudgett: subscription callbacks posted as a separate review https://gerrit.asterisk.org/6733 - I still have to work on the ao2_weakproxy_find so I'll get that reworked and rebased later. |
| 20:23.14 | Demon_VoIP | file: it is debug log from first "leg" of call: https://pastebin.com/aZFzSUDd where the same: Sample size different 480 vs 80 |
| 20:24.46 | file | that by itself is not a bug or issue |
| 20:26.46 | Demon_VoIP | file, ok. what can i do to here audio on destination? destination agent Phoner Lite. It shows IN: none; out: opus. |
| 20:27.49 | file | that's more of an #asterisk question, but you need to break it down and try to isolate things further |
| 20:57.34 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:57.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:18.26 | coreyfarrell | rmudgett: I think the updated ao2_weakproxy_find should solve the threading issues by not unlocking.. it no longer needs to unlock since subscription callbacks don't cause a lock order issue with proxy & container. |
| 21:46.38 | coreyfarrell | cresl1n: thank you (mailing list re: chan_sip). |
| 21:47.37 | cresl1n | coreyfarrell: I was waiting for everybody to get their perspectives out there |
| 21:48.55 | cresl1n | coreyfarrell: I see you didn't really way in on the discussion, other than to help with figuring the number of PJSIP bugs that are out there |
| 21:48.59 | cresl1n | *weigh |
| 21:49.03 | coreyfarrell | I mostly kept quiet because I'm not always that good at being polite, the msg you replied to annoyed me. |
| 21:49.28 | cresl1n | TBH, it was the one that bothered me the most |
| 21:49.38 | cresl1n | That's why I picked it |
| 21:49.40 | coreyfarrell | enough people have production issues with chan_pjsip that it's not necessary to say HEY IT LEAKS! |
| 21:50.30 | coreyfarrell | I've actually made lots of progress with the ability to test for leaks. with all my patches last try almost half of tests/channels/pjsip passed with ref_debug enabled. |
| 21:51.59 | coreyfarrell | I've done some spot checks since then with 'sleep(33)' in loader.c before it shuts down modules, this has resolved many of the remaining leaks. |
| 21:53.02 | coreyfarrell | unfortunately decreasing the timerb only helped certain situations and decreasing timert1 caused a bunch of test failures. so the full ref_debug test will take a long time to run. |
| 21:55.27 | coreyfarrell | cresl1n: about the number of bugs that's part of the reason I was asking about closing out the stale old bugs... |
| 21:56.16 | coreyfarrell | if you look at current bugs (any issue updated since asterisk 13 was released), pjsip and chan_sip have about the same number. |
| 21:57.16 | coreyfarrell | and any chan_sip bug that hasn't been touched in 3 years is 1) not going to get fixed and 2) likely either already fixed or not that big of a deal to current users. |
| 22:01.21 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:b4c4:899e:46b6:a94c) |
| 22:01.21 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:12.11 | rmudgett | coreyfarrell: Shh don't let seanbright hear you say that. He's been fixing several older issues lately. :) |
| 22:14.33 | coreyfarrell | rmudgett: many of the issues I'm talking about only say they were updated in 2014 because someone created a whole bunch of SWP tickets.. a lot of them are from 2011 and no action was ever taken on them. |
| 22:24.08 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:80df:b2c9:aa98:204b) |
| 22:24.09 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:25.45 | coreyfarrell | rmudgett: I can update the first review of the series whenever, I'll wait for you to say so I don't want to rebase the other commits if you're in the middle of posting findings. |
| 22:26.20 | rmudgett | k I'm looking at the second in the series now. |
| 22:27.03 | coreyfarrell | the second one is a lot simpler now that it doesn't have to worry about locking order between the container and the weak proxy. |
| 23:00.19 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 23:17.24 | coreyfarrell | rmudgett: when you have a minute could you tell me why I'd use a while loop? |
| 23:18.01 | rmudgett | Because any subscription callback wouldn't be able to do the unlink at the time. |
| 23:18.13 | rmudgett | You have the container locked. |
| 23:18.57 | coreyfarrell | oh wait I just got it the while loop would be if the container has more than one matching proxy it can find the second one after removing the first? |
| 23:19.22 | rmudgett | The loop ensures that when the read lock is upgraded that a proxy object doesn't sneak in. |
| 23:20.09 | rmudgett | yes it the while loop would ensure that there wouldn't be any other matching proxies. |
| 23:20.34 | rmudgett | s/yes it/yes/ |
| 23:21.12 | coreyfarrell | oh I hadn't realized that __adjust_lock would unlock and lock. |
| 23:22.52 | rmudgett | It has to do that to promote a read lock to a write lock. |
| 23:23.44 | rmudgett | And that's only for rw locks |
| 23:24.15 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-mqekebbpccqjwyhk) |
| 23:27.01 | coreyfarrell | ok I think I'm getting it. so as long as I 'keep stronger' it will go from read to write at first, but then stay upgraded. |
| 23:33.28 | rmudgett | yes |
| 23:36.33 | coreyfarrell | for sorcery can I start with a read lock then upgrade to write lock if I need to create an object? or is the __adjust_lock thing only for ao2 internals? |
| 23:37.56 | rmudgett | It's ao2 internals since __adjust_lock is prototyped in astob2_private.h |
| 23:38.46 | rmudgett | Thing is if the proxy was never in the container the lock wouldn't get promoted. |
| 23:39.33 | coreyfarrell | ahh.. so if the consumer of ao2_weakproxy_find were doing find only it can use ao2_rdlock, but if it's find_or_create like my cases it has to use ao2_wrlock from the start otherwise it could allow duplicate creation. |
| 23:40.55 | rmudgett | yes unfortunately |
| 23:42.32 | file | it's an annoying fact of life |
| 23:44.31 | coreyfarrell | rmudgett: about the \internal thing, nothing else in that file declares anything \internal so any objection if I just drop it as well? |
| 23:44.54 | rmudgett | no objection |