| 01:18.34 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-64.bstnma.fios.verizon.net) |
| 02:19.10 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 02:19.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:13.23 | *** join/#asterisk-dev CELYA_ (~Thunderbi@anantes-655-1-124-21.w90-59.abo.wanadoo.fr) |
| 05:48.29 | snuff-work | mm seanbright your probably right.. i'm not that great at knowing the 'pj' related commands.. will test your idea tomorrow |
| 07:46.55 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.14.178.189) |
| 07:47.16 | *** join/#asterisk-dev jkroon (~jkroon@41.113.22.246) |
| 09:02.42 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:33.01 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 12:33.01 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 12:56.39 | *** join/#asterisk-dev jkroon (~jkroon@41.113.22.246) |
| 13:01.26 | *** join/#asterisk-dev jkroon (~jkroon@41.113.22.246) |
| 13:03.30 | *** join/#asterisk-dev jkroon (~jkroon@41.113.22.246) |
| 13:09.28 | coreyfarrell | does anyone know of any technical reasons to not use `#tryinclude <config-type>.d/*.conf` in config files? for example `#tryinclude manager.d/*.conf` in manager.conf. the idea is to allow the user to avoid touching the baseline config installed by RPM and to make it easy for other packages to install configuration to /etc/asterisk/*.d/my-app.conf |
| 13:27.40 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 13:34.14 | gtjoseph | @coreyfarrell: no reason at all that I can think of. |
| 13:36.08 | file | ditto |
| 13:48.19 | *** join/#asterisk-dev jkroon (~jkroon@41.113.50.206) |
| 14:19.40 | file | seanbright: yeah I'm not sure what to do with this... |
| 14:33.20 | coreyfarrell | file: probably need a debug patch that disables frame.c caching and passes caller information from outside into ast_calloc so you can see what is allocating the frames? |
| 14:33.45 | file | potentially |
| 14:42.24 | *** join/#asterisk-dev jkroon (~jkroon@41.113.50.206) |
| 14:56.43 | coreyfarrell | file: unless you object I'm going to post a patch on the issue to do that and suggest he run with it and post updated malloc debug output |
| 14:56.50 | file | go for it |
| 14:57.11 | coreyfarrell | that way it will at least isolate which module is allocating the frames |
| 15:06.56 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-vfinkiochcawneqr) |
| 15:06.56 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:32.12 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-hrettgiuxkxmqnzy) |
| 15:32.12 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:47.15 | seanbright | file: do about what? |
| 16:47.35 | file | the frame leak, but coreyfarrell sorted that out for the moment |
| 16:47.40 | seanbright | ah. roger. |
| 16:48.29 | seanbright | i looked at my patch again and i don't see how it could be causing problems, but i've been wrong before (and often) |
| 16:48.40 | file | is it wrong to be right to be wrong? |
| 16:49.36 | seanbright | ask again later |
| 16:50.52 | seanbright | yeah, i looked again, it's not my patch |
| 16:51.01 | seanbright | i'm 99.99999% confident |
| 17:12.18 | *** join/#asterisk-dev alex2grad (26756428@38.117.100.40) |
| 17:13.51 | alex2grad | can not submit a patch to review on gerrit |
| 17:14.00 | alex2grad | You need 'Create' rights to create new references. |
| 17:14.07 | alex2grad | User: alexei_gradinari |
| 17:14.10 | alex2grad | Contact an administrator to fix the permissions |
| 17:14.53 | rmudgett | You'll need to update your review script because Gerrit was updated. There is an email on the dev list with a better explanation. |
| 17:15.12 | alex2grad | ok |
| 17:16.29 | rmudgett | gtjoseph: Maybe we should update the Gerrit usage wiki to mention the review script needs updating. |
| 17:16.41 | gtjoseph | yep. it's on ly list |
| 17:16.44 | gtjoseph | on my |
| 17:16.55 | rmudgett | The only thing on the list? |
| 17:17.05 | rmudgett | :D |
| 17:17.28 | gtjoseph | if only |
| 17:23.50 | kharwell | if you have only one thing in your list you can call that being a head. |
| 17:25.40 | bford | groans |
| 17:28.34 | gtjoseph | kharwell: did you come up with that on your own??? |
| 17:28.48 | gtjoseph | if so, i'm impressed |
| 17:29.31 | kharwell | ya just thought of it :-D |
| 17:29.36 | *** part/#asterisk-dev alex2grad (26756428@38.117.100.40) |
| 17:30.04 | gtjoseph | nerd humor |
| 17:30.41 | gtjoseph | or maybe it's a nerd dad joke |
| 17:39.52 | kharwell | so racy bridging. From from I can tell, and more testing, it does appear that if a bridge is not chosen due to a channel not being fully "setup" (in this case pjsip session still needing to apply/applying sdp), then a simple bridge is chosen vs. native (in this scenario), but once the session is complete the bridge is issued a reconfigure, which then chooses to switch to native |
| 17:41.22 | kharwell | So maybe not really a problem per se, although it can make automated testing hard. Also when the two channels enter the simple bridge a re-invite goes out due to a mismatch in channel topologies |
| 17:41.40 | file | nods |
| 17:42.00 | kharwell | Again not a huge deal for a scenario that only happens on occasion. |
| 17:42.17 | kharwell | Anyone think it's worth a patch? |
| 17:42.21 | kharwell | some patch in some way that is? |
| 17:42.52 | kharwell | can try to fix the race, can try to suppress the re-invite, something else? |
| 17:43.36 | kharwell | Not sure about fixing the actual race. It might be invasive or awkward at the least |
| 17:43.53 | file | is it reasonable to supress the re-invite in that particular scenario? |
| 17:44.25 | kharwell | can maybe suppress the re-invite, but the then how to distinguish between that and a legit inactive stream. Might need to add a new enum for "init" |
| 17:44.54 | file | I'd use the state of the SDP negotiator and stuff if possible |
| 17:45.15 | file | dunno, though, wouldn't spend too much time on it since the end result is correct - even if it takes a journey to get there |
| 17:46.25 | kharwell | yeah that's kinda where I am at. leaning toward not touching it for now |
| 17:46.39 | file | nods |
| 17:47.02 | kharwell | although how to get a test to ignore it might be tricky |
| 17:48.00 | file | with STYLE |
| 17:48.16 | kharwell | if only that was a SIPp option |
| 17:53.51 | coreyfarrell | file / seanbright: any feelings about making my frame malloc debugging patch something that can be merged? obviously master only but I'm thinking that instead of deleting the frame cache we just disable caching for defined(LOW_MEMORY) || defined(MALLOC_DEBUG) |
| 17:54.17 | file | I have no qualms |
| 17:56.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.99) |
| 18:51.41 | coreyfarrell | rmudgett: with the patch I'm doing for frame.c to bypass the cache when MALLOC_DEBUG is enabled means that nothing will call ast_calloc_cache with MALLOC_DEBUG enabled. do you think I should just get rid of that calloc variant? |
| 18:52.53 | rmudgett | I'd rather not to be safe. |
| 18:53.29 | coreyfarrell | the patch is for master only if you are concerned about ABI |
| 18:55.03 | rmudgett | I knew it was for master only because of the need for API changes to pass in caller location. I'd rather keep it for completeness. |
| 18:55.39 | coreyfarrell | err sorry for the noise, I see a call to it in iax :/ |
| 18:58.18 | rmudgett | Should your patch also make iax2 not use the cache? |
| 19:10.16 | coreyfarrell | rmudgett: I guess it should for the same reason. hadn't planned on touching iax but it'll be a simple change. |
| 21:54.47 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 21:54.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |